CSS fails when output type changed from HTML to PDF

This forum is for all Flare issues related to styles, stylesheets and XML.
Post Reply
KayJay
Propeller Head
Posts: 23
Joined: Tue Nov 29, 2016 7:19 am

CSS fails when output type changed from HTML to PDF

Post by KayJay »

Hi all,

I'm interested whether anyone can give me some insight as to why certain aspects of CSS fail to render when when the target's output type changes to PDF (using 2016 r2).

I have a scenario where I am using some pretty fancy CSS on the ::before pseudo-element to create a note style that looks like two table cells. When I set the output type to HTML, this renders correctly in the output and the preview window. However, if I switch the output type to PDF, leaving everything else the same, it neither renders correctly in the output or in the preview windows.

In the HTML+preview it looks like this:
html-note.jpg
and in the PDF+preview it looks like this:
pdf-note.jpg
I think the CSS that fails in the PDF build is related to the following, particularly the position attribute:

Code: Select all

.note::before {
  content: "Note";
  display: block;
  position: relative;
  left: -10px;
  width: 110%; /*or some other custom value*/
}
which together extends the yellow 'row' to each end to compensate for padding on the note body.
I find it very strange that the CSS processor works differently for HTML5 and PDF, especially when only in preview mode (not even in the browser!).

Any thoughts/suggestions? Should I log a bug?
Best,
Kristy
(Please excuse the egregious colors used for example purposes!)
You do not have the required permissions to view the files attached to this post.
SteveS
Senior Propellus Maximus
Posts: 2087
Joined: Tue Mar 07, 2006 5:06 pm
Location: Adelaide, far side of the world ( 34°56'0.78\"S 138°46'44.28\"E).
Contact:

Re: CSS fails when output type changed from HTML to PDF

Post by SteveS »

What does the output look like when you print it, rather than relying on Flare's preview?
Image
Steve
Life's too short for bad coffee, bad chocolate, and bad red wine.
NorthEast
Master Propellus Maximus
Posts: 6359
Joined: Mon Mar 05, 2007 8:33 am

Re: CSS fails when output type changed from HTML to PDF

Post by NorthEast »

The problem is that "Fancy CSS" will not work properly in a PDF.

I don't think there's a definitive list of what does and doesn't work, but you'll have problems using more 'advanced' CSS with PDFs.
For example, you need to be careful using - CSS psuedo selectors, complex selectors, positioning, floats, CSS3 properties.

Edit: I don't know if this will work, but maybe try a negative left margin rather than negative left positioning.
KayJay
Propeller Head
Posts: 23
Joined: Tue Nov 29, 2016 7:19 am

Re: CSS fails when output type changed from HTML to PDF

Post by KayJay »

It's the same in the actual PDF output as in the preview.
KayJay
Propeller Head
Posts: 23
Joined: Tue Nov 29, 2016 7:19 am

Re: CSS fails when output type changed from HTML to PDF

Post by KayJay »

OK, I guess I just shouldn't expect too much from the PDF processor. I will log a feature request though, in case it does result in better documentation about which attributes are not available.
nat
Jr. Propeller Head
Posts: 5
Joined: Mon Dec 15, 2014 4:41 pm
Location: Wellington, New Zealand

Re: CSS fails when output type changed from HTML to PDF

Post by nat »

I've been struggling with similar issues all week.

In particular, I discovered that the pseudo class selector :nth-child() is not handled correctly by the PDF processor (best to avoid it). In fact, :nth-child() can break formatting of other unrelated elements elsewhere on the page.

It's frustrating that there's no way to debug PDF formatting problems - you can't tell the difference between "mistakes in my CSS" versus "deficiencies in the PDF processor". Switching to a "clean XML" target and using the Chrome Inspector tool seems to be the nearest way to check that the CSS code is correct.

I agree it would be very helpful to have a list somewhere which describes the CSS limitations for PDF outputs.
Paulie
Sr. Propeller Head
Posts: 140
Joined: Sun Mar 01, 2015 3:01 pm

Re: CSS fails when output type changed from HTML to PDF

Post by Paulie »

KayJay wrote:OK, I guess I just shouldn't expect too much from the PDF processor. I will log a feature request though, in case it does result in better documentation about which attributes are not available.
Here's hoping that they come up with a complete list. The last time I asked for a list of which CSS was supported for each output type, I was basically told to make my own list!
"In an ideal world, software should be simple, well designed, and completely intuitive to end users. In the real world, good documentation is king."
chuck_agari
Sr. Propeller Head
Posts: 225
Joined: Wed May 30, 2018 2:40 pm

Re: CSS fails when output type changed from HTML to PDF

Post by chuck_agari »

Paulie wrote:
KayJay wrote:OK, I guess I just shouldn't expect too much from the PDF processor. I will log a feature request though, in case it does result in better documentation about which attributes are not available.
Here's hoping that they come up with a complete list. The last time I asked for a list of which CSS was supported for each output type, I was basically told to make my own list!
So they want customers to document their documentation product?
Rona Kwestel
Sr. Propeller Head
Posts: 212
Joined: Wed Apr 04, 2007 11:50 am

Re: CSS fails when output type changed from HTML to PDF

Post by Rona Kwestel »

Just bumped into this PDF CSS limitation. I have the following construct in my CSS to style the first 3 columns of a particular table type as "code":

Code: Select all

table.config td:nth-child(-n+3)
{
	font-family: monospace;
	color: #4169e1;
	mc-disable-glossary-terms: true;
}
It works like a charm in the HTML output, but styles all 4 columns as code in the PDF output, which has the unfortunate consequence of obfuscating specific terms in that 4th column that were explicitly styled as code to make them stand out from normal text.

One more reason to dump the PDF output altogether. It's the most hateful thing - you can't control the pagination, so you get awkward transitions from the bottom of one page to the top of the next, it doesn't support any of the interactive features you get with HTML output except for links, it forces you back into that 8 1/2" page-width limitation that kills your tables and diagrams, and constrains the presentation of material into a linear flow that doesn't allow for easy moving around between topics.
Post Reply