Convert them all to bold. That's the most noticeable upon visual inspection. A quick look over the back cover would make for an easy comparison.

Trust me, I do these kinds of bold/italics/underline visual inspection comparisons 10-50 times a day when posting press releases on a website i run...where my goal is to format it as close to the original as possible in regards to B/I/U.

In the amount of effort involved, removing them would be easier than inserting a start bold at this tick and end it on that tick but not if the tick precedes the letter S or if the tick is after an O if it's the first letter in the word (O'Mally), etc.

Though the S/O/etc rules would still need to be applied for removing ticks, just a lot less amount of logic going into it.

That's why I would be against any kind of automatic conversion.  Just let the people with the brains (you) who can decide what should be what update the profile.

Quoting nolesrule:

Quote:
Quoting lmoelleb:

Quote:
The "point" is basically the spearation of content and layout introduced with CSS (or rather "meant to be introduced with CSS" as CSS is not nearly powerfull enough to do this).

Sure it is. My graphic designer and I have been working toward converting our sites over to CSS-only layouts. The issue isn't CSS, it's microsoft's refusal to correctly implement it in IE, which requires extra hours of CSS tweaking. It just takes a little practice and experience.

Sorry, but I just expect more than CSS offers. If you ever had to change the order of two elemens in HTML in order to render something as you want, then you have seen a failure of separation between content and layout.

But back to the real discussion:

It has been argued that formatting isn't needed because the real formatting is available on the back cover scan. I am afraid it's not that simple as the DVD Profiler program itself is not the only way to view the collection and the back cover might simply not be available, or if it is available be in a format where you can't read the text (for example when you view the collection on your pocket pc). Hence I consider this argument void as it does not cover all use cases.

For font sizes I am personally against including them as I consider them to disruptive to the layout. They can change the appearance of the overview between profiles too much for my liking. Yes, I know this is my personal preference.

I also see a problem with font sizes: In the following example the size of the majority of the overview is used as a base (and hence 100% font size refers to the size of this text). If a cover starts with a header with font size 140%. Then comes a leading paragraph at 120% followed by for example three paragraphs at 100%. Some (including me) would want the main body to be normal font size. Others would want to make the header "big", the leading paragraph to be "normal", and the main body to be "small" in order to capture all the font sizes.

For the argument of being able to render the footnotes smaller it appears to me to be problematic as it tries to indicate how to render the text instead of what to render. Marking the footnote as a footnode instead of marking it as small text would leave it to the render engine to determine how footnodes should appear which would give a uniform appearance for all profiles - and allow changing this appearance easily without having to update any profiles.

But obviously this is my personal oppinion, and I realize others do not want bullet lists or they want the fonts etc. Lucklily the solution to allow this is quite trivial, so I start to wonder why I bothered writing the arguments against font sizes in the first place but now it is there so I' leave it

Obviously if we deside to include markup, it must be done in an XML fragment format (for example a subset of xhtml, but it's not important).

With the overview available in an XML fragment it is extremely simply to make a set of stylesheets. For example the following would be trivial to make:

Render as plain text (remove formatting)

Render formatting as ticks

Allow formatting but ignore font sizes

Full formatting

And it would probably not be to much work to allow custom XSLTs as well.

As far as I can see, the following problems must be addressed for this to work:

When editing the full set of formatting will be visible - and when uploading it must be included even if the user does not currently see the formatting with the XSLT they apply. This is obviously a question of educating the user but that might not be feasable.

We do not want to be swamped with voting, contributing etc. The following could address this:
When contributing: If a contribution does nothing but change ticks to formatting start/end tags, then just accept it without voting. Yes, this will potentially give a few errors but the alternative is to vote on every single overview which would overload everything so errors would slip though anyway. This might be done for a limited time period only.
When updating profiles: Run the currently selected XSLT against both the new and old text and compare the result. If the result is identical (for example because the change was a font formatting not displayed with the users XSLT) then mark it as such (and preferrably optionally allow it to be downloaded with no questions asked).

Quoting m.cellophane:

Quote:
If we get text effects for overviews, will we want them for titles, cast and crew, role names, etc? I hope not.

Agreed!

I have not commented on this yet ... but I am all for BOLD  underlined  and  italics

If we can just get these it would be great!

I think font sizing is going a little overboard. There would be too much arguing about what size would be correct.

We should just stick to the basics.
.

When ones considers that the overview is simply pure advertising hype designed to sell a DVD, our slavish recreation of it must make the studio marketing guys pee themselves with joy!