-
Notifications
You must be signed in to change notification settings - Fork 95
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
xetex rounds all image sizes to integer pt values #597
Comments
miktex seems to round with xetex all image sizes to full pt values:
gives with miktex:
and with texlive
|
Thanks @u-fischer! I have tried to trace this one and eventually got here:
miktex/Programs/TeXAndFriends/xetex/source/trans.h Lines 56 to 61 in b0c7a71
miktex/Programs/TeXAndFriends/xetex/source/XeTeX_pic.c Lines 92 to 164 in b0c7a71
miktex/Programs/TeXAndFriends/xetex/source/pdfimage.cpp Lines 55 to 121 in b0c7a71
As far as I can tell, all the dimension conversions seem to be correct (floats are used all the way). |
Sorry I have neither the will nor the time to skim through miktex sources. But as it works in texlive (both in new and older versions) I have some doubts that the source of the problem is directly in the xetex sources. |
I agree on that. |
Thank you both for your efforts. Please keep in mind that XeTeX uses a bunch of 3rd party libraries (see |
MiKTeX
|
Compiling the "with 12pt" version with pdflatex
xelatex
|
I have managed to find the root cause of the horizontal differences. After noticing the following difference between
for the following MWE:
Root cause is the length of
On the other hand, here is what we have within
I guess my findings are not MiKTeX-specific, and I would like to submit my proposal at the appropriate address. (Horizontal differences in my original MWE can be suppressed explicitly setting |
Sorry I hadn't realized that you were still fighting also with the horizontal displacement, or I have told you that it is the \parindent. But this is not a miktex specific problem and should not be discussed here, the right place to suggest changes to the standard classes is the latex2e github. But your chances that \parindent is changed are slim - it would affect to many existing documents, a feature request would be closed. If you want a fix parindent size, set it in your document. |
I understand the impact. On the other hand, if there are no issues for |
Horizontal differencesThey are not MiKTeX-specific. The root cause is explained here: latex3/latex2e#381. Explicitly setting Vertical differencesTo be continued... |
miktex/Programs/TeXAndFriends/xetex/source/XeTeX_pic.c Lines 105 to 109 in de8b955
Where does
|
Essentially, it is what @u-fischer found out: the width, height and depth of
|
Interestingly, (what @u-fischer found out) it seems that the wrong dimensions are present even for JPEG (probably for other non-PDF formats as well). I see that different code (libs) are being used, meaning that the issue is present not only in one place? Or maybe there is an unique issue in postprocessing (of both)? PDF: miktex/Programs/TeXAndFriends/xetex/source/XeTeX_pic.c Lines 105 to 109 in b0c7a71
JPEG: miktex/Programs/TeXAndFriends/xetex/source/XeTeX_pic.c Lines 116 to 124 in b0c7a71
|
Hi @edocevoli. I am keen to help with debugging and resolving this issue. Can you please instruct how to set up the dev environment? (In general, I cannot find such instructions.) |
I finally managed to build and do some testing and logging. Let's recall that the original graphics dimensions are 40 mm x 40 mm. Additionally, we have 40 mm = 113.385826772 pt (PostScript) = 113.811023622395 pt (TeX) (up to some numeric precision).
113.81522 pt are correct (pdflatex). On the other hand, 113.0 pt are not (xelatex). Adding logs into XeTeX_pic.c and pdfimage.cpp I find that these dimensions are reported: 113.39 pt (PostScript) = 113.815 pt (TeX).
It seems that 3rd party library works correctly, and that dimensions are rounded after calling |
The issue definitely lies in postprocessing. |
Hi @edocevoli. Here is the root cause... When setPoint(corners[0], xField(bounds), yField(bounds));
setPoint(corners[1], xField(corners[0]), yField(bounds) + htField(bounds));
setPoint(corners[2], xField(bounds) + wdField(bounds), yField(corners[1]));
setPoint(corners[3], xField(corners[2]), yField(corners[0])); are translated to: setpoint (corners[ 0 ], xfield (bounds), yfield (bounds));
setpoint (corners[ 1 ], xfield (corners[ 0 ]), yfield (bounds) + (C4P_integer) htfield (bounds));
setpoint (corners[ 2 ], xfield (bounds) + (C4P_integer) wdfield (bounds), yfield (corners[ 1 ]));
setpoint (corners[ 3 ], xfield (corners[ 2 ]), yfield (corners[ 0 ])); where two Why do they even appear here? Does the original source code somehow suggest that Eventually, there are tens of thousands My guess is that C4P grammar must be updated, at least these four sections: miktex/BuildUtilities/c4p/gram.y Lines 1734 to 1741 in e4b8ca4
miktex/BuildUtilities/c4p/gram.y Lines 1796 to 1803 in e4b8ca4
miktex/BuildUtilities/c4p/gram.y Lines 1812 to 1819 in e4b8ca4
miktex/BuildUtilities/c4p/gram.y Lines 1868 to 1875 in e4b8ca4
|
Thank, the grammar should certainly reviewed. Some of the explicit |
For the record, there are 83 files with 31485 occurrences of
Additionally:
|
In the old days, C/C++ compiler did produce better (faster) code than C/C++. And nowadays, it is hard to find a working Pascal compiler.
|
I have removed the wrong casts. This should fix the issue. |
Hi, for the following MWE I cannot get the same PDF output using
pdflatex
andxelatex
- the graphics are slightly displaced (both horizontally and vertically) in the version produced byxelatex
. Interestingly, without specifying the12pt
the horizontal difference is lost but vertical is still present. (My MiKTeX is updated.)all_files_and_logs.zip
Comparisons:
There are no such issues in the latest TeX Live, though -
pdflatex
andxelatex
produce (respectively) the same PDF output as MiKTeX'spdflatex
.I am not sure if there are some issues in the binaries, the class definitions (the impact of
12pt
), or even in thegraphicx
bundle. Maybe MiKTeX is not synced with CTAN, I really cannot tell anything else - but something is fishy.There is a long story in the background of this issue, given in the following links:
Regards, Ivan
The text was updated successfully, but these errors were encountered: