Hello,
I’m relatively new to ConTeXt (version 2024.05.31, LMTX, standalone) and really enjoy learning it so far, but I have one little problem with the appearance of horizontal bars in math mode.
It seems the way ConTeXt displayed horizontal extensible bars in math mode some time ago (as used in \frac, \sqrt, \overbar, ...) was similar to the way LaTeX (PDFLaTeX and LuaLaTeX) and Plain TeX handled this, but it has changed since then. Instead of one bar there are now multiple characters attached to each other.
This makes it look more consistent with the font, but unfortunately it doesn’t display well in any PDF viewer I’ve tried (on Linux, so I’ve not tried Adobe Acrobat Reader). The bars look dotted, I guess it’s due to anti-aliasing (the dots disappear when anti-aliasing is disabled, but then of course everything looks pixelated). Two screenshots are attached (different zoom levels in PDF viewer) so that you know what I’m talking about.
Source: \setuppapersize[S3] \starttext \startformula \sqrt{a^2 + b^2} = \frac{1000 \cdot c}{1000} \stopformula \stoptext
Is there a way to switch to the old bars for documents viewed mainly on screens, or is there any other way to improve their appearance? I couldn’t find any documentation on this, so I would be very thankful if somebody here could help out.
Best, Ralph
Hi Ralph,
I don’t see any pixels in the PDF file when I typeset your code snipet (on MacOS 11.7.10). Here is what I get.
Best regards: Otared
On 13 Jun 2024, at 13:10, Ralph ralph.2718@email-postfach.info wrote:
Hello,
I’m relatively new to ConTeXt (version 2024.05.31, LMTX, standalone) and really enjoy learning it so far, but I have one little problem with the appearance of horizontal bars in math mode.
It seems the way ConTeXt displayed horizontal extensible bars in math mode some time ago (as used in \frac, \sqrt, \overbar, ...) was similar to the way LaTeX (PDFLaTeX and LuaLaTeX) and Plain TeX handled this, but it has changed since then. Instead of one bar there are now multiple characters attached to each other.
This makes it look more consistent with the font, but unfortunately it doesn’t display well in any PDF viewer I’ve tried (on Linux, so I’ve not tried Adobe Acrobat Reader). The bars look dotted, I guess it’s due to anti-aliasing (the dots disappear when anti-aliasing is disabled, but then of course everything looks pixelated). Two screenshots are attached (different zoom levels in PDF viewer) so that you know what I’m talking about.
Source: \setuppapersize[S3] \starttext \startformula \sqrt{a^2 + b^2} = \frac{1000 \cdot c}{1000} \stopformula \stoptext
Is there a way to switch to the old bars for documents viewed mainly on screens, or is there any other way to improve their appearance? I couldn’t find any documentation on this, so I would be very thankful if somebody here could help out.
Best, Ralph
<small.png><zoomed.png>___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________
Otared Kavian e-mail: otared@gmail.com Phone: +33 6 88 26 70 95
On 13 Jun 2024, at 21:04, Otared Kavian otared@gmail.com wrote:
Hi Ralph,
I don’t see any pixels in the PDF file when I typeset your code snipet (on MacOS 11.7.10). Here is what I get.
Best regards: Otared
<fraction-bar-pixels.pdf>
I see it on both - the original and Otared's.
Otared: If open yours (on MacOS 14.5) by double-clicking the image in the email and clicking zoom+ twice then the 'wobble' in the line is visible if you squint.
Bound to be monitor and resolution dependent as well though - not sure how to provide settings that would be repeatable by others. Just go up and down zoom sizes looking carefully.
— Bruce Horrocks Hampshire, UK
On 6/13/2024 10:04 PM, Otared Kavian wrote:
Hi Ralph,
I don’t see any pixels in the PDF file when I typeset your code snipet (on MacOS 11.7.10). Here is what I get.
No problems on windows on chrome-os either. Mikael S and I checked it on his linux box and one can indeed see anti aliasing when taking a screen dump (depends on resolution).
So it's a linux rendering issue when taking dumps. That said: we can't do anything about it. Using rules (traditional approach) is pretty bad in screen dumps and even regular rendering, depending on zoom; there one has interaction between the font rendering and other graphic elements (rules).
Btw, vertical extensibles are not different (take the bracket which has similar constructs). Interesting is that it is straight blob connections that can show these occasional gray pixels and it only seems to happen with a little overlap. Kind of a bug we think.
Hans
ps. One reason when I always use (x)ubuntu when i have to use a linux desktop is that it always was set up right wrt rendering fonts and anti aliasing. I might need to check that.
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am 13.06.24 um 23:13 schrieb Hans Hagen via ntg-context:
On 6/13/2024 10:04 PM, Otared Kavian wrote:
Hi Ralph,
I don’t see any pixels in the PDF file when I typeset your code snipet (on MacOS 11.7.10). Here is what I get.
No problems on windows on chrome-os either. Mikael S and I checked it on his linux box and one can indeed see anti aliasing when taking a screen dump (depends on resolution).
So it's a linux rendering issue when taking dumps.
Not only. It also happens with all(?) PDF viewers on MacOS – at least 10.14 and 10.15, can anyone confirm with current versions?
So it’s dependend on the screen rendering, anti aliasing settings (that you usually can’t influence).
It doesn’t affect printing – or does it for anyone? I can imagine printing from Firefox, i.e. pdf.js, is affected, since it prints only in screen resolution.
Hraban
On 6/14/2024 9:35 AM, Henning Hraban Ramm wrote:
Am 13.06.24 um 23:13 schrieb Hans Hagen via ntg-context:
On 6/13/2024 10:04 PM, Otared Kavian wrote:
Hi Ralph,
I don’t see any pixels in the PDF file when I typeset your code snipet (on MacOS 11.7.10). Here is what I get.
No problems on windows on chrome-os either. Mikael S and I checked it on his linux box and one can indeed see anti aliasing when taking a screen dump (depends on resolution).
So it's a linux rendering issue when taking dumps.
Not only. It also happens with all(?) PDF viewers on MacOS – at least 10.14 and 10.15, can anyone confirm with current versions?
So it’s dependend on the screen rendering, anti aliasing settings (that you usually can’t influence).
hm, so i have to stick to windows for viewing (and an ancient hardware laptop in order to avoid copilot and recall) but i'll check ubuntu anyway
It doesn’t affect printing – or does it for anyone? I can imagine printing from Firefox, i.e. pdf.js, is affected, since it prints only in screen resolution.
it's not related to math then, as there are also ligatures built this way, although often they often are less sensitive to thsi due to generous overlaps (unless they use a sequence of connecting strokes in the same direction)
also keep in mind that looking at a blown up character is not that realistic (for instance a traditional bitmap font might look great at 600 or 1200 dpi at intended size so zooming in showing raggedness is not the normal way to see it)
btw, if one wants to observe inaccuracy, just zoom in in graphics made by drawing programs (even of famous companies)
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 14 Jun 2024, at 11:44, Hans Hagen via ntg-context ntg-context@ntg.nl wrote:
On 6/14/2024 9:35 AM, Henning Hraban Ramm wrote:
Am 13.06.24 um 23:13 schrieb Hans Hagen via ntg-context:
On 6/13/2024 10:04 PM, Otared Kavian wrote:
Hi Ralph,
I don’t see any pixels in the PDF file when I typeset your code snipet (on MacOS 11.7.10). Here is what I get.
No problems on windows on chrome-os either. Mikael S and I checked it on his linux box and one can indeed see anti aliasing when taking a screen dump (depends on resolution).
So it's a linux rendering issue when taking dumps.
Not only. It also happens with all(?) PDF viewers on MacOS – at least 10.14 and 10.15, can anyone confirm with current versions?
Artifacts like mentioned were visible in Preview on my Mac (14.5) as well.
The PDF view in chrome on this Mac shows a slightly different artifact effect, see image below.
Neither bothers me, though.
Best wishes, Taco
— Taco Hoekwater E: taco@bittext.nl genderfluid (all pronouns)
Hi,
thank you all for your replies so far. I guess I’ll have to live with that for now (of course this isn’t really a problem, but a bit unpleasant to look at when you’re used to the straight lines in LaTeX). Just wanted to add that I can see this artifacts quite clearly on a 13 inch 1080p screen in the PDF viewer (depends on zoom level, on some zoom levels I see nothing) and not only when enlarging a screenshot. After all, it’s visible in my attached screenshots even if displayed in their original resolution. (Naming of my screenshots wasn’t very clear, zoomed.png is zoomed-in in the pdf viewer, not a zoomed-in screenshot.)
Best, Ralph
On 6/15/2024 10:59 AM, ralph.2718@email-postfach.info wrote:
Hi,
thank you all for your replies so far. I guess I’ll have to live with that for now (of course this isn’t really a problem, but a bit unpleasant to look at when you’re used to the straight lines in LaTeX). Just wanted to add that I can see this artifacts quite clearly on a 13 inch 1080p screen in the PDF viewer (depends on zoom level, on some zoom levels I see nothing) and not only when enlarging a screenshot. After all, it’s visible in my attached screenshots even if displayed in their original resolution. (Naming of my screenshots wasn’t very clear, zoomed.png is zoomed-in in the pdf viewer, not a zoomed-in screenshot.)
The "left radical + rule" isn't perfect either, because it depends on overlap. Depending on the font you can see issues at the connection (actually these might be obscured by aliasing at low res). You can try that outside lmtx with different fonts.
Also, because rules are often rendered differently from glyphs (and rules can use either a line or rectangle fill) it's always been an issue (which is also why engines have some heuristics for choosing one or the other method).
And, as mentioned, vertical extenders also use the same etechnology as we now use for radicals, it's just that there was never a concept like that in engines for radicals. Arrows sit in the same category and also use the same glyphs so there one can observe the same. Actually, even in traditional tex arrows are made from minusus and an arrowhead overlapping piecewise.
Maybe viewers will catch up.
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 -----------------------------------------------------------------
-
Bruce Horrocks -
Hans Hagen -
Henning Hraban Ramm -
Otared Kavian -
Ralph -
ralph.2718＠email-postfach.info
-
Taco Hoekwater