For reasons I won't get into, I need/want to embed all my style sheets into the head of my html document. Attached is the input file and log file produced from the following command line:

/opt/ESPlannerWeb/bin/prince --server --media=print --input=html --javascript "/tmp/services/mdd/26/prince.html" "prince.pdf" -v --debug --log=prince.log

None of the styles are applied to the generated PDF. I'm probably doing something REALLY obviously wrong, but when I apply a style sheet via the command line that includes all of these, things work, so I'm a little puzzled.

Anyway, if someone has a suggestion as to what I'm doing wrong when I try to embed things, make it and I'll probably give myself a dope slap and thank you.

Best,

Dick Munroe

1. prince.html‎ 573.2 kB ‎
   Input file
2. prince.log‎ 29.3 kB

There is a @media print rule in the style sheets that overrides most of the style, is this what you want?

Well, no, but everything still styled correctly before I tried embedding the style sheets. I've pulled the @media and gotten the same results, so that's a red herring, the styles are still not being applied.

Can you attach a PDF of the output you are getting? Also, which version of Prince are you using?

8.1r5 but the same thing happens with both 9 and the latest release of 10. We're stuck with 8.1r5 for financial reasons.

1. prince.pdf‎ 256.6 kB ‎
   Generated PDF

Edited 17 Oct 2016 by richard.c.h.munroe@gmail.com

Some more information.

After a fair amount of experimentation, I found something that gets me what I what. I had to use <link> tags and put everything in the right order.

However, whenever I tried to use explicit http URLs to access the CSS, the styles were, again, not applied (server logs indicate the files were accessed by Prince).

So, this works:

<link ref="stylesheet" href="/amds/bootstrap/css/bootstrap.css" />

but this does not:

<link ref="stylesheet" href="http://site.host.name/amds/bootstrap/css/bootstrap.css" />

Identical behavior in 8.1r5, 9, and 10.

Best,

Dick Munroe

Edited 21 Oct 2016 by richard.c.h.munroe@gmail.com

A shot in the dark: are the CSS files sent with the right Content-Type header? No idea if Prince is strict about the content-type though..

Announcement: repos for tests/utils

It's straightforward HTML and given that the link works without the HTTP. Much of the css is also used to style the HTML version of the reports and those work out of the box so I don't think this is the problem.

Best,

Dick Munroe

Hi Richard, exactly because the LINK tag works when the file is *not* loaded over HTTP I was thinking the problem might be caused by something in the HTTP traffic. I've now tested this a little locally, and I see exactly the problem you describe if the server sends wrong or lacking Content-Type header for the CSS file, Prince will output a console warning

warning: unexpected CSS MIME type 'application/octet-stream'

and not apply the file.

AFAIK this is required by the CSS specification or something, because browsers do the same thing. For browsers, it's usually a competitive advantage to be more permissive of mistakes so it's quite surprising that this strictness has survived

What is the URL to your stylesheet? Have you tried loading it in a browser and check the headers in its developer tools?

Announcement: repos for tests/utils

Edited 22 Oct 2016 by hallvord

Nope, when I access the CSS files via HTTP, Chrome tells me that the response headers content type is:

Content-Type: text/css

Best,

Dick Munroe

p.s. the log file I included, above, doesn't have any warnings in it.

This is very puzzling. But if the files are being accessed by Prince as indicated by the server logs, perhaps this brings us back to the original situation where the styles were embedded in the input document but not applying as expected?

Pretty much. The only time I've been able to get the styles applied is if I access them as files. Nothing else seems to work. We've worked around the problem for now but the solution is non-optimal as it requires manual synchronization of two code bases.

Best,

Dick Munroe

Ops, sorry - I should have checked the log before going on about the possible content-type issue.

I've attempted to test this locally, this is how:

1) I saved your HTML file from above, moved the CSS to a separate file (removing any intermingled STYLE start/end tags).

2) Added a LINK tag loading this style sheet from http://localhost where I have a local server running

3) Ran Prince, passing the name of the local file

Unfortunately I get the same rendering whether the style is inside the HTML file, loaded from a local file with a LINK tag, or loaded from a server with a LINK tag. The Prince-specific print CSS is applied as expected, creating page breaks and footers.

The generated document does however look much like the PDF you attached above, so now I'm a bit confused Is there any particular styling that is missing from that document?

Announcement: repos for tests/utils

This is what the document should look like if the styles are correctly applied (attached).

1. prince-correct.pdf‎ 303.3 kB

Thanks for posting that! I'm investigating the problem..

Announcement: repos for tests/utils

More than welcome. I should have done that in the first place. My apologies.

Things like the blue TH background is overridden by

  .table td,
  .table th {
    background-color: #fff !important;
  }

inside the @media print block which starts on line 196. This overrides other code because of the !important statement.

The TOC links are not blue because color: inherit; is set for among others .h1 and .h2 on line 1124, I suppose an ancestor is styled with color:black in the print-specific styles somewhere.

In general, these issues are also shown if you open the page in a web browser and use its print preview function. That is a strong indication there's some conflict between the print-specific CSS and the other CSS code. Perhaps it's possible and a good idea to somewhat simplify the style sheets here, at least try to reduce the usage of "!important" since it can easily get confusing..

Announcement: repos for tests/utils

Edited 30 Oct 2016 by hallvord