Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Precision issues with high dpis and drawquad #6

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Eolien55
Copy link

Hello,

This pull request includes 2 commits very useful when using high DPIs (7200 is enough to trigger bugs).

The first makes drawquad more aligned with what a true circle quadrant should like using Bézier curves. Moreover, when using high DPIs, the calculations would overflow (especially the sign test). To fix overflow and precision issues, replacing long's by double's is enough.

The second commit fixes pdfpos and pdfunit. For similar reasons, these 2 functions concentrated much of the overflows of neatpdf. Replacing 32-bit integers by 64-bit might have been enough, but the calculations used to simulate decimal numbers are the source of many rounding errors, which are problematic when precision is needed (eg, when using grap). Replacing the long's by double's is, here too, sufficient.

Thanks for the work you put in your very fine pieces of code,
Regards,
Elie Le Vaillant

The preceding code resulted in errors making the
circles and ellipses look odd, compared to the
ps's ones.

The magic value b had to be replaced by a double,
for precision purposes.

Large dpis cause overflow on `ch*cv`. To address
this problem, we multiply the signs instead of
the numbers themselves.
ints are 32-bit. Some users may use very high
dpis (eg, 720000). pdfpos00(x*100, y*100) makes
for frequent overflows, since x, y and dev_res
can be very large.

Doubles in pdfpos and pdfunit calculations:

This is very important when precision is required
(eg, when using grap). When ints are used instead,
the output is very choppy since lines' ends fall
only on points with integer coordinates (this
problem doesn't arise in ps because coordinates
are not divided by dev_res, so integer coordinates
are almost like floats because they are so dense).

This is also very problematic for tbl.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant