Forum Bugs

oddly inaccurate rendering of PDF in Chrome; others work fine

johnathonwright
I'm an experiencing an odd issue with an SVG chart. Opening this PDF in chrome, it appears that the yellow section is touching the green section. When the PDF is opened in the os-x "reader" app, safari, and firefox, the PDF version appears exactly as it does in the HTML. Three color bars which do not touch each other. See attached screen shot.

For diagnostic purposes, I have included higher-stroke-width.pdf, which appears to show that circles aren't co-centric. Which is strange because their perimiters appear to be the same.

We are using Prince 15.4.1\nCopyright 2002-2023 YesLogic Pty. Ltd.

Any thoughts about how to get this so that it will work in the Chrome and Chromium browser?

Thank you so much.
Johnathon Wright

Logs from Prince:

Thu Nov 21 22:46:51 2024: loading document: /usr/lib/prince/license/license.dat
Thu Nov 21 22:46:51 2024: Loading document...
Thu Nov 21 22:46:51 2024: loading HTML5 input: thing.html
Thu Nov 21 22:46:51 2024: loading document: thing.html
Thu Nov 21 22:46:51 2024: Applying style sheets...
Thu Nov 21 22:46:51 2024: Preparing document...
Thu Nov 21 22:46:51 2024: Converting document...
Thu Nov 21 22:46:51 2024: loading font: /usr/share/fonts/truetype/liberation2/LiberationSerif-Regular.ttf
Thu Nov 21 22:46:51 2024: used font: Liberation Serif, Regular
Thu Nov 21 22:46:52 2024: error: Figure structure element is missing alternative text on page 1
Thu Nov 21 22:46:52 2024: error: not identifying as PDF/UA-1 due to problems in structure tree
Thu Nov 21 22:46:52 2024: writing PDF to file: thing.pdf
Thu Nov 21 22:46:52 2024: finished: success
Thu Nov 21 22:46:52 2024: ---- end
  1. Screenshot 2024-11-21 at 5.53.47 PM.png1.2 MB
    screenshot demonstrates inconsistency
  2. chart-repro.html2.3 kB
    HTML that produces the issue
  3. chart-repro.pdf13.3 kB
    reproduction of issue
  4. higher-stroke-width.pdf13.3 kB
    shows that circles aren't co-centric

Edited by johnathonwright

wezm
I did some investigation and it seems like this is a bug in PDFium stemming from the use of a negative dash phase in the PDF. I have opened an issue on the Chromium bug tracker:

https://issues.chromium.org/issues/380308811

In meantime you can probably work around the issue if you find positive values for 'stroke-dashoffset' in the SVG that yield the result you're after.
mikeday
We have added a workaround to the latest build to avoid this problem with Chrome, hopefully that helps!