On Wednesday, 2 November 2022 18:19:37 GMT joerg van den hoff wrote: > > I believe the reason is because the glyph for the sqrtex/radicalex which > > groff delivers in the Symbol font actually overlines the following glyph, > > and it is the definition in ps.tmac which "corrects" this so that it > > works for eqn. Other fonts which have their own sqrtex glyph actually > > overline themselves (rather than what follows), so they don't need the > > same correction. > > > > What happens if you include the command > > > > .rchar radicalex > > > > to remove this correction? > > nothing, AFAICS: same result as before. I admit I do not (yet or > forever...?) quite understand the the whole thing. but as said, in my case > there is definitely no own (font-defined/provided) sqrtex glyph involved. > those fonts (e.g. DejavuSansMono) don't have that. so I guess they should > behave like the standard fonts and just used the groff mechanism (replace > sqrtex by radicalex and whatever adjustments are in place to make it work > with eqn). but as the example shows, there is a visible-to-massive > misalignment (mostly horizontally but also vertically), depending on font.
Command should be:- .rchar \[radicalx] sorry. My expectation is that any font which does not contain sqrtex/radicalex itself which then uses the glyph from Symbol font, will have a space after the sqrt, but if the font has its own sqrtex/radicalex (like Garamond) all will be good. The .rchar command does not make the glyph "unknown" to groff, it removes a pseudo definition of the glyph which has been defined by the .char command, so it will then use the actual glyph of the same name. > and if .rchar radicalex is supposed to make that glyph unknown to groff, I > do not understand, why my pdf does not change and groff does not complain? > it seems the sqrtex->radicalex substitution is performed irrespective of > the attempt to rm radicalex with the `.rchar' directive? > > also, regarding my example pdf from last mail, to be clear: I did not use > eqn there, rather those square roots are specified as a string: > > .ds longroot \\[sqrt]\\[sqrtex]\\[sqrtex]\\[sqrtex]\\[sqrtex] > > and then interpolated in the examples for different fonts. > > another detail I just have noted: as, said, in my example file, out of the 3 > external fonts (Garamond, Optima, DejavuSansMono) none does define a sqrtex > glyph, but Garamond actually *does* have its own radicalex glyph and that > one is in fact used, it seems, as indicated by the differing line thickness > of the extension bar for that font in the example pdf. and this > font-internal radicalex seems to be defined (for Garamond, anyway) such > that it overlines the _preceding_ glyph (which happens to be the square > root glyph here...) but repetitions of the glyph do not do that but > properly extent the bar. or so it seems. Also, in ps.tmac, \[sqrtex] is made a synonym for \[radicalex], which is why groff is using \[radicalex] from the Garamond font. The .rchar command above should fix the problem of the misplaced over line. The other fonts which define their own sqrt but not a sqrtex it would be an accident if the glyph in the symbol font exactly matched the sqrt in the text font. Cheers Deri > so there seem to be several distinct (but somehow related) issues: > > * the case discussed in the bug reports #62923 and #63179 where the font > defines its own sqrtex > > * the case I have now observed with Garamond where the font defines its own > radicalex. and this glyph seems then to be found by the fallback > substitution sqrtex -> radicalex (rather than the radicalex from the S > font) > > * the case where the external font does not have either sqrtex or radicalex > (like the standard fonts, I understand). here, the standard fallback > substitution happens, but the extension bar is not properly aligned > relative to preceding sqrt glyph. but what I *now* see is the following > which kinda explains the last issue (maybe the others as well?): > > the tested fonts (Optima, Garamond, DejavuSansMono) do _all_ define there > own sqrt glyph in all styles R, I, B, BI and the standard fonts (Times, > Palatino etc) do *not* do that, only the symbols font does. > > so my tentative explanation is: the mechanism implemented by groff > explicitly assumes that both sqrt and radicalex are the glyphs defined by > the symbols font and only for those sqrt and extension bar are properly > aligned. if either sqrt or/and radicalex are found in the font, those > glyphs are used, but seemingly using metric information or other implicit > assumptions that are only valid for the symobls font. -- does that make any > sense?? > > a workaround seems to be to enforce usage of sqrt and radicalex from S font > and to just ignore those glyphs' definition in the font files. indeed > removing the "offending" glyphs from the font file resolves the issue (as > is to be expected :)). > > best, > joerg
