CSS fails when output type changed from HTML to PDF

This forum is for all Flare issues related to styles, stylesheets and XML.

CSS fails when output type changed from HTML to PDF

Postby KayJay on Tue Jan 03, 2017 9:25 am

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.
KayJay
Propeller Head
 
Posts: 23
Joined: Tue Nov 29, 2016 7:19 am

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

Postby SteveS on Tue Jan 03, 2017 2:42 pm

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.
SteveS
Propellus Maximus
 
Posts: 1980
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).

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

Postby Dave Lee on Wed Jan 04, 2017 1:31 am

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.
Dave Lee
Master Propellus Maximus
 
Posts: 5676
Joined: Mon Mar 05, 2007 8:33 am
Location: UK

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

Postby KayJay on Wed Jan 04, 2017 1:33 am

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

Postby KayJay on Wed Jan 04, 2017 1:43 am

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.
KayJay
Propeller Head
 
Posts: 23
Joined: Tue Nov 29, 2016 7:19 am

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

Postby nat on Wed Aug 08, 2018 7:11 pm

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.
nat
Jr. Propeller Head
 
Posts: 4
Joined: Mon Dec 15, 2014 4:41 pm
Location: Wellington, New Zealand

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

Postby Paulie on Thu Aug 09, 2018 6:01 pm

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."
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

Postby chuck_agari on Wed Sep 05, 2018 4:38 pm

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?
chuck_agari
Sr. Propeller Head
 
Posts: 194
Joined: Wed May 30, 2018 2:40 pm

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

Postby Rona Kwestel on Tue Aug 13, 2019 12:01 pm

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.
Rona Kwestel
Sr. Propeller Head
 
Posts: 208
Joined: Wed Apr 04, 2007 11:50 am


Return to Styles, Stylesheets and XML

Who is online

Users browsing this forum: No registered users and 2 guests