Hello, I compared latest ConTeXt standalone (LuaTeX 2.08) against TeX Live 2020 (LuaTeX 1.12). The produced PDFs are: https://miletic.net/lipsum-112.pdf https://miletic.net/lipsum-208.pdf Viewing them with Evince (and I assume Adobe Reader, I don't have it at hand to test) shows only minor differences in (horizontal) character spacing, which I would expect; the text looks reasonably good either way. However, viewing them with PDF.js shows a large difference: https://miletic.net/lipsum-pdfjs-112.png https://miletic.net/lipsum-pdfjs-208.png As you can observe, b, m, n, p, and r (and possibly others) are moved slightly above other letters. Is this the expected behavior? If not, is this an issue with the way PDF.js is displaying the PDF or the way LuaTeX is producing it? Thanks in advance. Regards, Vedran Miletić -- Vedran Miletić vedran.miletic.net
On 1/7/2021 10:10 PM, Vedran Miletić wrote:
Hello,
I compared latest ConTeXt standalone (LuaTeX 2.08) against TeX Live 2020 (LuaTeX 1.12). The produced PDFs are:
https://miletic.net/lipsum-112.pdf https://miletic.net/lipsum-208.pdf
Viewing them with Evince (and I assume Adobe Reader, I don't have it at hand to test) shows only minor differences in (horizontal) character spacing, which I would expect; the text looks reasonably good either way. However, viewing them with PDF.js shows a large difference:
https://miletic.net/lipsum-pdfjs-112.png https://miletic.net/lipsum-pdfjs-208.png
As you can observe, b, m, n, p, and r (and possibly others) are moved slightly above other letters. Is this the expected behavior? If not, is this an issue with the way PDF.js is displaying the PDF or the way LuaTeX is producing it? what lua does your 2.08 have? if it's 5.2. then such small differences can be a side effect of lua (different number models), serialization of numbers (default accuracy), or maybe rounding in the lua=>tex font interface (there were some fixes iir), the number of digist that the backend uses, etc
anyhow, so what you see (in the file) is (per line) transform matrices that are slightly different so what you then see is rounding to the device pixels i wouldn't loose sleep over it .. nowadays fonts also evolve and that gives larger differences Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 07. 01. 2021. 23:01, Hans Hagen wrote:
what lua does your 2.08 have? if it's 5.2. then such small differences can be a side effect of lua (different number models), serialization of numbers (default accuracy), or maybe rounding in the lua=>tex font interface (there were some fixes iir), the number of digist that the backend uses, etc
It's whatever ConTeXt standalone has. I don't have any extra Lua installed: $ luametatex --version This is LuaMetaTeX, Version 2.08.11 Execute 'luametatex --credits' for credits and version details. There is NO warranty. Redistribution of this software is covered by the terms of the GNU General Public License, version 2 or (at your option) any later version. For more information about these matters, see the file named COPYING and the LuaTeX source. Functionality : level 20210107 Support : context@ntg.nl Copyright : The Lua(Meta)TeX Team(s) (2005-2020+) The LuaMetaTeX project is related to ConTeXt development. This macro package tightly integrates TeX and MetaPost in close cooperation with Lua. $ luatex --version This is LuaTeX, Version 1.13.0 (TeX Live 2021/dev) Execute 'luatex --credits' for credits and version details. There is NO warranty. Redistribution of this software is covered by the terms of the GNU General Public License, version 2 or (at your option) any later version. For more information about these matters, see the file named COPYING and the LuaTeX source. LuaTeX is Copyright 2020 Taco Hoekwater and the LuaTeX Team. Typing lua gives command not found and texlua is system one.
anyhow, so what you see (in the file) is (per line) transform matrices that are slightly different so what you then see is rounding to the device pixels
Should I see it on non-HiDPI as well? Because it seems it's there. Regards, Vedran
i wouldn't loose sleep over it .. nowadays fonts also evolve and that gives larger differences
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
-- Vedran Miletić vedran.miletic.net
On 1/8/2021 12:39 AM, Vedran Miletić wrote:
It's whatever ConTeXt standalone has. I don't have any extra Lua installed:
--credits should mention the lua version
Should I see it on non-HiDPI as well? Because it seems it's there.
depends on what you consider (non) hdpi ... the positioning of glyphs depends on font scale, rounding of stems and such (hints in fonts but these get less relevant with high res displays), caching, inter glyph corrections (that pdftex/luatex/...) put in the text stream to resync within certain tolerances, etc ... (often a print is a better reference as displays are seldom 600+ dpi) .. it's also why often expansion looks bad on screen because even a sub percentage difference can give such effects Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Fri, 8 Jan 2021, Hans Hagen wrote:
On 1/8/2021 12:39 AM, Vedran Miletić wrote:
It's whatever ConTeXt standalone has. I don't have any extra Lua installed:
--credits should mention the lua version
Should I see it on non-HiDPI as well? Because it seems it's there.
depends on what you consider (non) hdpi ... the positioning of glyphs depends on font scale, rounding of stems and such (hints in fonts but these get less relevant with high res displays), caching, inter glyph corrections (that pdftex/luatex/...) put in the text stream to resync within certain tolerances, etc ... (often a print is a better reference as displays are seldom 600+ dpi) .. it's also why often expansion looks bad on screen because even a sub percentage difference can give such effects
Another way to see it is just zoom in on the PDF. If the artifacts go away on zooming in, then they are due to anti-aliasing. Aditya
08. 01. 2021. u 05:41, Aditya Mahajan piše:
On Fri, 8 Jan 2021, Hans Hagen wrote:
On 1/8/2021 12:39 AM, Vedran Miletić wrote:
It's whatever ConTeXt standalone has. I don't have any extra Lua installed:
--credits should mention the lua version
Should I see it on non-HiDPI as well? Because it seems it's there.
depends on what you consider (non) hdpi ... the positioning of glyphs depends on font scale, rounding of stems and such (hints in fonts but these get less relevant with high res displays), caching, inter glyph corrections (that pdftex/luatex/...) put in the text stream to resync within certain tolerances, etc ... (often a print is a better reference as displays are seldom 600+ dpi) .. it's also why often expansion looks bad on screen because even a sub percentage difference can give such effects
Another way to see it is just zoom in on the PDF. If the artifacts go away on zooming in, then they are due to anti-aliasing.
Aditya
Thanks to both of you for the detailed explanations. Printed page shows no artifacts and neither does PDF.js when the text is zoomed. So it is an issue with anti-aliasing after all. I'll report it to PDF.js and see what they tell me. Regards, Vedran -- Vedran Miletić vedran.miletic.net
participants (3)
-
Aditya Mahajan -
Hans Hagen -
Vedran Miletić