Re: Broken font in branch deri-gropdf-ng
On Mon, Aug 07, 2023 at 12:39:12AM +0100, Deri wrote: On Sunday, 6 August 2023 16:53:28 BST Nikita Ivanov wrote: Hi, Deri Thank you for improving PDF support, especially fixing the issue with Unicode characters within the outline. I've discovered a bug where one of my fonts does not render properly. I've attached an archive containing the fonts, a troff file and produced PostScript and PDF files. The font is supposed to be Times New Roman, but, in the resulting PDF, regular and bold styles are rendered with a different font--seems like it's a default font on my system. I get these errors when viewing the PDF file with zathura: error: FT_New_Memory_Face(VVMHFM+TimesNewRomanPSMT): invalid argument warning: ignored error when loading embedded font; attempting to load system font error: FT_New_Memory_Face(KUTWST+TimesNewRomanPS-BoldMT): invalid argument warning: ignored error when loading embedded font; attempting to load system font Regards, Nikita Hi Nikita, Thanks for the report (and the thanks). I've found the bug in the code, I did not allow for hyphens being used in postscript glyph names. It is now fixed and I've attached a copy the latest gropdf (only to be used if you are running the deri-gropdf-ng branch). It was a single character addition to a regexp in line 4590 (line 4602 in the attached gropdf since it includes Colin Watson's patch). Let me know if this fixes it for you, and keep on testing. :-) Cheers Deri It work properly now, thank you!
Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number
> > It's an issue with eqn material inside a macro definition. > > To avoid expanding eqn-generated escapes at macro definition > > time, bracket the macro definition with ".ec #" (or some other > > unused character) and ".ec" (to restore backslash as the escape > > character after the macro definition). This way, backslashes > > are retained in the macro and escapes are only evaluated at > > macro expansion time. > If this problem is not only in-line EQN code but also .EQ/.EN code, EQ/EN and in-line eqn code are identical. > then it would seem to me that any EQN code inside a groff/troff > macro is to be avoided. Anything else seems like a recipe > for disaster. Not at all. One only has to understand what causes these issues and then handle them appropriately. Normally, one would double all backslashes inside a macro definition because escapes are also evaluated at macro definition time (copy mode). Each double backslash is interpreted as a single backslash inside the macro, so that the "real" interpretation of the escapes is delayed until macro expansion time (when the macro contents are re-read and all still existing escapes are re-interpreted). However, eqn doesn't have a "double all backslashes" option to be used inside a macro definition (and even if it did, how would eqn know which code is in a macro and which isn't, without doing all the work that troff does?). The solution is to not interpret backslashes at macro definition time. This is achieved by declaring a different character[*] to be used as the escape character before defining the macro, and reinstating backslash as the escape character after the macro definition(s). This approach can also be used independently of eqn if you simply want to avoid all the backslash-doubling hassle while defining macros. Obviously, when using this approach to deal with eqn code inside macros that also contain other escapes, you must not double the other non-eqn backslashes in the macro either. On the other hand, sometimes you *do* want escapes to be evaluated at macro read time (e.g., converting \t to a tab), in which case you would have to use the new escape character instead of the backslash. [*] I recommend ascii BEL = control-G because it is unlikely to be used elsewhere in the manuscript.
Re: geometric primitives (was: interviews with groff developers)
>From the user's perspective, I think simplest would be if "line" took a "fill" attribute subject to the constraint that the line ends where it begins, something pic can enforce. In that case, it would draw a solid polygon instead of a sequence of lines. I once looked into the code to see if that would work. Unfortunately, in pic each segment (identified by "to") is independent, The most obvious fix would be to introduce a new kind of object, "polygon", with line-like syntax, but a new (variable-length) data structure, and an alternate way to record "to" phrases. In short, it was not as easy as I had imagined, and I was too lazy to follow up on the idea. Folks may be amused by how I actually fill polygons in pic. I break them up into boxes and right triangles. Each triangle is described as a filled box that spans the triangle's three corners. Then the PostScript is edited to delete the extra corner. Doug
