depth of glyph nodes with y_displacement<0
Hi, I found a curiosity in LuaTeX's treatment of `y_displacement` in glyph nodes: Take the following ConTeXt example: \usetypescript[pagella] \setupbodyfont[pagella,12pt] \starttext f\char776\char776\char776\char807\char807\char807\vrule \stoptext (See https://github.com/latex3/luaotfload/issues/134 for a more practical case where this leads to issues) Here the \vrule shows that the marks attached at the top get their y_displacement added to their height, while for the marks added at the bottom the additional depth is ignored. (The first \char807 is still covered by the rule because that is the natural height of this glyph) This is explicitly done in texnodes.c: For glyph_height, the displacement is always added. For glyph_depth, the displacement is only added if it is positive: scaled glyph_height(halfword p) { scaled w = char_height(font(p), character(p)) + y_displace(p); if (w < 0) w = 0; return w; } scaled glyph_depth(halfword p) { scaled w = char_depth(font(p), character(p)); if (y_displace(p) > 0) w = w - y_displace(p); if (w < 0) w = 0; return w; } This seems inconsistant. Is there a reason why this would be required or could it be changed to handle height and depth consistently? Best regards, Marcel
On 3/12/2020 3:16 PM, Marcel Fabian Krüger wrote:
Hi,
I found a curiosity in LuaTeX's treatment of `y_displacement` in glyph nodes:
Take the following ConTeXt example:
\usetypescript[pagella] \setupbodyfont[pagella,12pt] \starttext f\char776\char776\char776\char807\char807\char807\vrule \stoptext
(See https://github.com/latex3/luaotfload/issues/134 for a more practical case where this leads to issues)
Here the \vrule shows that the marks attached at the top get their y_displacement added to their height, while for the marks added at the bottom the additional depth is ignored. (The first \char807 is still covered by the rule because that is the natural height of this glyph)
This is explicitly done in texnodes.c: For glyph_height, the displacement is always added. For glyph_depth, the displacement is only added if it is positive:
scaled glyph_height(halfword p) { scaled w = char_height(font(p), character(p)) + y_displace(p); if (w < 0) w = 0; return w; }
scaled glyph_depth(halfword p) { scaled w = char_depth(font(p), character(p)); if (y_displace(p) > 0) w = w - y_displace(p); if (w < 0) w = 0; return w; }
This seems inconsistant. Is there a reason why this would be required or could it be changed to handle height and depth consistently? It is (among some others) a known artifact that dates from the very early days when we played with alternative par builders and such. These offsets were introduced when we were messing around with arabic and had to handle marks and at the same time deal with tex's perspective on line dimensions (which it doesn't really have): prevdepth, maxdepth and such so this is (irr) why we handled the depth differently.
Because in the process more access to node lists at various stages was implemented one can indeed wonder if we need to keep this assymetrical approach (as we were never really bitten by it there was not real reason to change is, also because it can resuel in incompatible output.) Anyway, what I can do is change it in luametatex so that for a longer period we can see if context users run into issues and complain about a change in output (i can then quickly revert to make it some option). After all, context users know that they are possible victims of testing. Just changing something in luatex right away is no option given the demand for stability, and definitely not in code freeze time. When we don't run into problems we can then decide to do it in luatex too (assuming that complaints about different output don't backfire). Another option is to introduce a parameter \characteroffsetmode: 0 = no compensation 1 = ht compensation (current and default) 2 = dp compensation 3 = ht and dp compensation (This could be done a couple of weeks after the code freeze as there is some more pending.) 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 Thu, Mar 12, 2020 at 06:43:39PM +0100, Hans Hagen wrote:
This seems inconsistant. Is there a reason why this would be required or could it be changed to handle height and depth consistently? It is (among some others) a known artifact that dates from the very early days when we played with alternative par builders and such. These offsets were introduced when we were messing around with arabic and had to handle marks and at the same time deal with tex's perspective on line dimensions (which it doesn't really have): prevdepth, maxdepth and such so this is (irr) why we handled the depth differently.
Because in the process more access to node lists at various stages was implemented one can indeed wonder if we need to keep this assymetrical approach (as we were never really bitten by it there was not real reason to change is, also because it can resuel in incompatible output.)
Anyway, what I can do is change it in luametatex so that for a longer period we can see if context users run into issues and complain about a change in output (i can then quickly revert to make it some option). After all, context users know that they are possible victims of testing.
Just changing something in luatex right away is no option given the demand for stability, and definitely not in code freeze time. When we don't run into problems we can then decide to do it in luatex too (assuming that complaints about different output don't backfire).
Another option is to introduce a parameter \characteroffsetmode:
0 = no compensation 1 = ht compensation (current and default) 2 = dp compensation 3 = ht and dp compensation
IMHO such a parameter sounds like a good idea. Another approcach I could think of would be to assign some unused bits in the glyph subtype to control this on a glyph-by-glyph basis. Especially that could help if there are some weird fonts which set up their glyphs in odd ways and would cause trouble if compensation is applied. Best regards, Marcel
On Thu, Mar 12, 2020 at 06:43:39PM +0100, Hans Hagen wrote:
This seems inconsistant. Is there a reason why this would be required or could it be changed to handle height and depth consistently? It is (among some others) a known artifact that dates from the very early days when we played with alternative par builders and such. These offsets were introduced when we were messing around with arabic and had to handle marks and at the same time deal with tex's perspective on line dimensions (which it doesn't really have): prevdepth, maxdepth and such so this is (irr) why we handled the depth differently.
Because in the process more access to node lists at various stages was implemented one can indeed wonder if we need to keep this assymetrical approach (as we were never really bitten by it there was not real reason to change is, also because it can resuel in incompatible output.)
Anyway, what I can do is change it in luametatex so that for a longer period we can see if context users run into issues and complain about a change in output (i can then quickly revert to make it some option). After all, context users know that they are possible victims of testing.
Just changing something in luatex right away is no option given the demand for stability, and definitely not in code freeze time. When we don't run into problems we can then decide to do it in luatex too (assuming that complaints about different output don't backfire).
Another option is to introduce a parameter \characteroffsetmode:
0 = no compensation 1 = ht compensation (current and default) 2 = dp compensation 3 = ht and dp compensation
IMHO such a parameter sounds like a good idea. Another approcach I could think of would be to assign some unused bits in the glyph subtype to control this on a glyph-by-glyph basis. Especially that could help if there are some weird fonts which set up their glyphs in odd ways and would cause trouble if compensation is applied. redefining the subtype is definitely something incompatible because
On 3/13/2020 3:16 PM, Marcel Fabian Krüger wrote: those bits in the subtype are 'free to use' so not for the engine to take ... weird fonts cans be dealt with using virtual font entries ... so: a future release (1.13) will have this \startsubsection[title={\type{\glyphdimensionsmode}}] Already in the early days of \LUATEX\ the decision was made to calculate the effective height and depth of glyphs in a way that reflected the applied vertical offset. The height got that offset added, the depth only when the offset was larger than zero. We can now control this in more detail with this mode parameter. An offset is added to the height and|/|or subtracted from the depth. The effective values are never negative. The zero mode is the default. \starttabulate[|l|pl|] \DB value \BC effect \NC\NR \TB \NC \type {0} \NC the old behavior: add the offset to the height and only subtract the offset only from the depth when it is positive \NC \NR \NC \type {1} \NC add the offset to the height and subtract it from the depth \NC \NR \NC \type {2} \NC add the offset to the height and subtract it from the depth but keep the maxima of the current and previous results \NC \NR \NC \type {3} \NC use the height and depth of the glyph, so no offset is applied \NC \NR \LL \stoptabulate ----------------------------------------------------------------- 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, Mar 13, 2020 at 03:34:04PM +0100, Hans Hagen wrote:
On 3/13/2020 3:16 PM, Marcel Fabian Krüger wrote:
On Thu, Mar 12, 2020 at 06:43:39PM +0100, Hans Hagen wrote:
This seems inconsistant. Is there a reason why this would be required or could it be changed to handle height and depth consistently? It is (among some others) a known artifact that dates from the very early days when we played with alternative par builders and such. These offsets were introduced when we were messing around with arabic and had to handle marks and at the same time deal with tex's perspective on line dimensions (which it doesn't really have): prevdepth, maxdepth and such so this is (irr) why we handled the depth differently.
Because in the process more access to node lists at various stages was implemented one can indeed wonder if we need to keep this assymetrical approach (as we were never really bitten by it there was not real reason to change is, also because it can resuel in incompatible output.)
Anyway, what I can do is change it in luametatex so that for a longer period we can see if context users run into issues and complain about a change in output (i can then quickly revert to make it some option). After all, context users know that they are possible victims of testing.
Just changing something in luatex right away is no option given the demand for stability, and definitely not in code freeze time. When we don't run into problems we can then decide to do it in luatex too (assuming that complaints about different output don't backfire).
Another option is to introduce a parameter \characteroffsetmode:
0 = no compensation 1 = ht compensation (current and default) 2 = dp compensation 3 = ht and dp compensation
IMHO such a parameter sounds like a good idea. Another approcach I could think of would be to assign some unused bits in the glyph subtype to control this on a glyph-by-glyph basis. Especially that could help if there are some weird fonts which set up their glyphs in odd ways and would cause trouble if compensation is applied. redefining the subtype is definitely something incompatible because those bits in the subtype are 'free to use' so not for the engine to take ...
That is good to know, could this be added to the documentation? Given that the engine used bits are called "valid bits", I always assumed that the remaining bits are reserved.
weird fonts cans be dealt with using virtual font entries ... so:
a future release (1.13) will have this
\startsubsection[title={\type{\glyphdimensionsmode}}]
Already in the early days of \LUATEX\ the decision was made to calculate the effective height and depth of glyphs in a way that reflected the applied vertical offset. The height got that offset added, the depth only when the offset was larger than zero. We can now control this in more detail with this mode parameter. An offset is added to the height and|/|or subtracted from the depth. The effective values are never negative. The zero mode is the default.
\starttabulate[|l|pl|] \DB value \BC effect \NC\NR \TB \NC \type {0} \NC the old behavior: add the offset to the height and only subtract the offset only from the depth when it is positive \NC \NR \NC \type {1} \NC add the offset to the height and subtract it from the depth \NC \NR \NC \type {2} \NC add the offset to the height and subtract it from the depth but keep the maxima of the current and previous results \NC \NR \NC \type {3} \NC use the height and depth of the glyph, so no offset is applied \NC \NR \LL \stoptabulate
Thank you. Best regards, Marcel
On 3/13/2020 3:56 PM, Marcel Fabian Krüger wrote:
That is good to know, could this be added to the documentation? Given that the engine used bits are called "valid bits", I always assumed that the remaining bits are reserved.
the protect run adds 255 so >=256 is protected (which in itself means nothing, read: whatever meaning ones gives to it) (it sort of reflects the "good old tex" distinction between a character and a glyph but we only have glyphs) so values 0..255 are kind of free to use (but there are some conventions about them identifying single shapes or ligature shapes that one can then act upon) 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 -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Marcel Fabian Krüger