Log in / Register

Forum › Bugs

Text Precision Problem

macki
Hi,

my problem is about text precision generation compare to html view (Chrome, latest version).

The red line in test.html is displayed on the different text position on the generated pdf.

Do you know what is the reason for that? Is it possible somehow fix it?
  1. Gabriola.ttf‎ 1.8 MB
  2. arial.ttf‎ 778.6 kB
  3. test.html‎ 4.0 kB
  4. test.pdf‎ 14.0 kB
macki
Ok, the problem was in roundig pt to px in Chrome and Prince PDF. Applying px to font size and line-height seems to solve a problem.

Could you tell me how Prince rounds pt (points) during pdf generation?

Edited by macki

mikeday
Prince rounds to the 4th decimal place, and treats px and pt units very similarly, where 96px = 72pt.
macki
Thanks Mike,
I have a problem with pdf size. For some value of @page size Prince generates additional white line on the top of pdf document. Could you help me with that?

Given html code:

<html>
<head>
<style type='text/css'>@page { margin:0; size: 375px 338px } </style>
<body style=''><div>
<p style='width:9.9218749875cm; height:8.9164583221cm; background-color:rgba(200,100,200,0.3);margin:0; padding:0;position:relative;'></p></div>
</body>

</head>
</html>

  1. Problem.pdf‎ 2.0 kB
mikeday
That's weird, which PDF viewer are you using? I see a white gap around the page in Evince, but not in Acrobat Reader or MuPDF.
macki
I was testing this issue in Adobe Reader and Nitro Reader. The problem is very similar setting given values:
@page { margin:0; size: 100mm 1px }
@page { margin:0; size: 100mm 2px }
@page { margin:0; size: 100mm 3px }

Margin from top on generated PDF is somehow generated randomly. I think it is ok when value of pixels is divisible by 4 e.g for 4px it seems to be ok in Adobe Reader and Nitro. Do you know how we can solve this problem?
mikeday
It seems that we are rounding page sizes to the nearest point, eg. 1/72", which leads to a slight discrepancy with the size of the content on the page. We will investigate this issue.
macki
Do you think we can use this command: prince.setOptions("--css-dpi=96") ?
mikeday
That will change the physical size that pixels correspond to, eg. if you specify --css-dpi=72 then px will be exactly equivalent to pt. Specifying 96dpi won't do anything, as that is already the default value.

It depends on how big you want the output to be, and exactly where these numbers are coming from. We can probably change the page size rounding behaviour in a future release of Prince.
macki
oh, I see.
Do you know when this problem could be fixed by developer team?
mikeday
Probably within a week. Which platform are you running Prince on?

In the meantime, you can workaround it by specifying page size in pt instead of px, guaranteeing that it will use that exact size.
macki
We are running Prince on Windows 2008 Server (Developers use Windows 7 or later).

Thanks Mike.
mikeday
We have now updated the latest builds for Windows, which include the change to page sizes.
ontic
@mikeday Are you able to confirm/check whether the issue with rounding page size has been fixed? Whilst testing and using the page dimensions:

size: 84mm 66mm;

When I open the generated PDF in Illustrator the page dimensions are:

Width: 83.96 mm Height: 65.97 mm

If this is the expected behaviour, can you offer an alternative for getting the precise dimensions above? I have already tried using points (238.11pt 187.09 pt) which still gave the same result.

My environment is:

Windows 10 Pro
Prince 10 rev 7
mikeday
This behaviour is changed in Prince latest builds, but not in Prince 10.
mikeday
The fix is included in Prince 11, available now.