What CSS3 support would you like to see added for PDF output

[iand]

I think that adding support for some CSS3 commands would help produce better quality PDF output. As a result I thought I would start a thread to see if anyone else would like specific commands and to try to encourage Madcap to support them.

Personally, I would like to see background-size and background-position supported. Background-size allows you to scale a background image using a percentage or set the x and y dimensions for the image in supported units. These two commands would make it easy to do the following:

warning.png

in PDF output using two lines of CSS without messing around with lots of nested divs. See http://forums.madcapsoftware.com/viewto ... it=warning for details. Without background-size and proper support for background-position you end up with the following:

warning wrong size.png

Ian

[LTinker68]

Although that's great in theory, it will make things difficult if you're using the same content for multiple targets types, specifically WebHelp. If you're delivering PDF and WebHelp output, then you'd need to duplicate that paragraph in your example and condition one out relative to your target, so that you'd have one version for use with WebHelp output (using CSS2) and one version for PDF output (using CSS3). And if MadCap were to add support for CSS3 for PDF output only, then they'd need to indicate in the Stylesheet Editor which attributes are CSS3 so that those designing WebHelp don't select that attribute by mistake.

[SteveS]

And don't forget to lodge your enhancements: https://www.madcapsoftware.com/bugs/submit.aspx

[iand]

Although that's great in theory, it will make things difficult if you're using the same content for multiple targets types, specifically WebHelp. If you're delivering PDF and WebHelp output, then you'd need to duplicate that paragraph in your example and condition one out relative to your target, so that you'd have one version for use with WebHelp output (using CSS2) and one version for PDF output (using CSS3). And if MadCap were to add support for CSS3 for PDF output only, then they'd need to indicate in the Stylesheet Editor which attributes are CSS3 so that those designing WebHelp don't select that attribute by mistake.

Hi Lisa, you have a good point and I agree this should be taken into account and might rule out some CSS3 commands for now. However, I think that we already have this situation to some extent as there are quite a few CSS2.1 commands which are unsupported or poorly supported in some output formats. I think some of the CSS3 commands also degrade gracefully in web browsers that don't support them e.g. border-radius. The use of different CSS for print media and web media should also alleviate this problem to some extent.

One clarification, I should have said print output in my previous post rather than just PDF.

I guess I am thinking primarily of CSS3 commands that add functionality which is print specific. What do you think about adding support for background-size and background-position for example? I would love to dispense with the clumsy tables that I have to use to get round the lack of these features. I notice that Prince XML has a command background-image-resolution which appears to do a similar task. I would really like to see Flare reaching its full potential for print output and PDF output in particular so it can be a true Frame competitor in the PDF output stakes. I think full support for CSS2.1 plus support for some key CSS3.0 commands would go some way to achieving this.

Cheers

Ian

[LTinker68]

I'd love some of the advanced style options available via CSS3, but it would require a lot more work on MadCap's part to be able to easily distinguish CSS1 and CSS2 styles from CSS3 styles in the GUI, plus you have the whole learning curve of explaining to the end user what those mean and why they have to stick to CSS1 and CSS2 if they're doing online output. MadCap would need to clearly mark which styles weren't supported in which browsers and would need to be able to throw explicit and descriptive errors codes warning the user that they have a WebHelp target, for example, but they selected a CSS3 style.

The only alternative would be to add CSS3 support just for Blaze, since it's for print output only, but then what do you do for all the Flare users who produce print output?

In other words, you add functionality for print output at the expense of the single source capabilities in Flare. MadCap could theoretically do it, but it would require a LOT of programming to support single sourcing with varying CSS capabilities.

[KevinDAmery]

Just musing aloud here... what if you put a "CSS Version" selector in each target? Then, when you do a build, code could be added to the CSS in the medium that the target uses to support that CSS level. This would allow you to enable CSS3 for PDF but not for WebHelp simply by enabling CSS3 in the PDF target but keeping it at CSS2 for the WebHelp target.

Seems logical - which means there's probably some enormous gotcha in there that I missed

[LTinker68]

Other than the learning curve of explaining to end users which CSS version can be used, that sounds like a good solution to me. The stylesheet could even default to putting CSS2 for the default medium.

The only thing I'm not sure about is what support -- if any -- Word has for the CSS versions. We already know it doesn't like pulling images when used as backgrounds for DIVs or bullets and it doesn't like DIVs altogether. So that would probably complicate things.

[owenf]

i would definitely like to see the CSS3 multiple columns support for print; column-count etc that would be great. it would solve a problem i'm having now.

[cbdebris]

I want rounded corners.

[owenf]

the word wrap word break thing so that you can force table cells to break and wrap long strings rather than expanding the container ... i want better control of my printed tables