|From:||joerg van den hoff|
|Subject:||Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)|
|Date:||Thu, 3 Nov 2022 19:42:17 +0100|
|User-agent:||Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1|
On 03.11.22 18:08, Deri wrote:
On Thursday, 3 November 2022 13:32:46 GMT joerg van den hoff wrote: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.ah, ok then. mission report: this (.rchar \[radicalex]) infact makes output sane for the Garamond font (which does have it's own glyph for that). BUT: doing the same thing for, e.g., Palatino (or any other font which does *not* have a radicalex glyph) messes up previously sane output: know there the root renders as _ √Brilliant, exactly what I predicted above, good for Garamond (which has its own radicalex), terrible for any other font which uses the glyph from Symbol. The reason, as I have explained in https://savannah.gnu.org/bugs/?62923 is because the radicalex in the symbol font is weird, see also https:// savannah.gnu.org/bugs/?63179. So the fix in ps.tmac which you .rchared should only really be applied if the glyph is being sourced from the S font.i.e. large gap between sqrt and the extensionbar. is this to be expected?[...]it does for Garamond but at the same time deteriorates/corrupts output from fonts not having the radicalex glyph to start with...Again, as predicted.
yes, you are right :). (and I actually overlooked that part of your mail. my fault...)
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.yes, that much at least I've understood already :).Good, so you have found the answer. If the sqrt comes from the text font and sqrtex comes from Symbol the glyphs are not designed to work together.
my question would be: what should groff do in such cases? naively, I would say it would be better if groff would unconditionally use sqrt and radicalex from the S font (even if one or both are provided by the used external font) to circumvent this issue and to produce sane looking square roots all the time. is this a bad idea?
what I do not understand is: when consistently removing any radicalex and sqrt glyphs (none of the considered fonts as a sqrtex glyph at all, anyway) from all font definition files, should this not lead to exactly identical behaviour regarding square root drawing with all those fonts since, I presume, in this case the same machinery will be invoked as for the standard fonts (all of which do not have those glyphs at all, too)? or is there some hardcoded tweak involved that explicitly checks the font name and does something peculiar in case it is one of the standard fonts? in any case, doing the above (removing radicalex and sqrt glyphs from the font definition files of the external fonts does not achieve exactly identical rendering. attached a q&d demo (I reiterate: all font-internal definition of sqrt and radicalex are removed from the external font definition files):I'm afraid the sqrt2.pdf is not helpful because it has not been produced by
but faithfully pasted together from that ;). it was just intended as a visual head-to-head comparison between those example fonts. but otherwise not helpful, yes.
groff, please can you do the same as your original sqrt.pdf (without the .rchar) using your patched fonts with sqrt removed.
to simplify(?) things, and pars pro toto, I've attached the pdf (always via grops) produced from this input: .\"-------------------- .nf \s36\f[DMI]\[sqrt]\[sqrtex] \s36\f[PI]\[sqrt]\[sqrtex] .\"--------------------where DMI is my "private" font description for DejavuSansMono (edited to remove the sqrt glyph (no radicalex anyway)). maybe this "squeezed"
display facilitates the direct comparison of both square roots (the top one preceded by font switch to DMI, the bottom one by font switch to PI (palatino italics). with my "ghostscript" viewers under X11 (gv and mupdf) it displays like in attached s1.png. viewing the same pdf with the MacOS default viewer ("Preview") renders it like in s2.png. as said, it seems a known issue that the MacOS quartz pdf engine has some quirks/bugs andnever has displayed groff-derived pdf output completely properly (especially equations, large brackest etc.). in the present case it is somewhat remarkable, that the misalignment between sqrt and radicalex is not visible here. but nevertheless the width of both extensionbars is obviously different. so there still *is* a discrepancy. NB: comparing s2.png to s1.png, one also can see that the sqrt is rendered rather differently per se: the slant of the upslope part is different in both cases.
in any case, s2.png is only attached to emphasize that under MacOS this different issue (pdf engine broken in that it interprets groff-produced pdf not quite right) might cause confusion. OTOH, acrobat viewer renders it (see. s3.png) identical to mupdf/gv. so this should be the "true" result.
for completeness, the dit output for the above troff input is: x T ps x res 72000 1 1 x init p1 x font 11 S f11 s36000 V12000 H72000 md DFd Csqrt H70092 Cradicalex h39672 n12000 0 V24000 H72000 Csqrt Cradicalex h37764 n12000 0 x trailer V792000 x stopwhich also seems to proof that the pdf output in fact only uses the S font. and although I am not that fluent in "reading dit" it also seems that the `H' and `h' commands indeed cause different position and length of the radicalex, no? question being: why?
it really mystifies me, why those "mute" font switches (PI and DMI never used for any glyphs in the document source) have an adverse influence on the formatting of the sqrt+radicalex (at least in the DMI case). why does this happen (and how to prevent it happen in the first place...)?
if you want/need more information, just let me know. best, joerg
Description: Adobe PDF document
Description: PNG image
Description: PNG image
Description: PNG image
|[Prev in Thread]||Current Thread||[Next in Thread]|