Follow-up Comment #17, bug #67830 (group groff): On Monday, 26 January 2026 18:10:49 GMT you wrote: > Follow-up Comment #16, bug #67830 (group groff): > > At 2026-01-26T12:27:50-0500, Deri James wrote: >> Follow-up Comment #15, bug #67830 (group groff): >> >> Most strange!! Two files I attached got uploaded, but not my comments:- >> >> JPM and CSS are "dummy" fonts, I don't really understand why they were >> added to gropdf. > > This information is in the "NEWS" file. > > NEWS: > > * groff now ships font description files usable with the "ps", "html", > "xhtml", and "utf8" output devices
No mention of pdf.
> to support East Asian fonts.
> (Caveat: with few exceptions, groff does not ship font files
> themselves.)
> These are intended as abstractions of faces to permit
> consistent naming while allowing custom font selections, just as with
> the 12 text typefaces supported across output devices for Latin
> scripts in groff (three families of four styles each).
I.e. TimesRoman = TR:Regular, TI:Italic, TB:Bold, TBI:BoldItalic
I suppose this is the bit vvv I don't understand, sorry.
> These CJK
> font descriptions are not organized into groff font families, but are
> similarly arranged.
CJK fonts normally do not have italic faces, but several include latin
characters as well, so fonts with those italicised can exist. They do have
multiple weights, JPM is using a "light" face, but different weights are
available. My japanese fonts are called GR and GB (Gothic) and MR and MB
(Mincho). This seems closer to the groff way.
>
> CSH: Simplified Chinese, Hei style
> CSS: Simplified Chinese, Song style
> CTH: Traditional Chinese, Hei style
> CTS: Traditional Chinese, Song style
> JPG: Japanese, Gothic style
> JPM: Japanese, Mincho style
> KOG: Korean, Gothic style
> KOM: Korean, Mincho style
>
> Thanks to TANAKA Takuji.
>
>> Even in grops they produce nothing useful,
>
> They should, if the names resolve to fonts you have installed.
I altered the "internalname" in JPM to GRyuminPro-Light (which is an otf font
I have installed on the system) and ran:-
[derij@pip Translate (master)]$ printf ".ft JPM\nハローワールド"|
test-groff -Tps -
Kutf8 | ps2pdfwr - JPM.pdf
**** Warning: glyf overlaps cmap, truncating.
[derij@pip Translate (master)]$ pdffonts JPM.pdf
name type encoding emb
sub uni object ID
------------------------------------ ----------------- ---------------- ---
--- --- ---------
NCAQQR+GRyuminPro-Light Type 1C Custom yes
yes no 7 0
As you can see, ghostscript has found the system font and embedded it
(although with a warning), but if you view the pdf the page is blank, and if
you do a text copy where the text should be, when you paste it comes out as
"ÏíüïüëÉ" - not japanese. If you use gv to look at the postscript,
before it
gets converted to pdf, it is just a blank page.
Please can you give instructions on how you tested the new code, so I can
duplicate your results.
>> and if you run ghostscript on the postscript file produced you get;-
>>
>> Warning: glyf overlaps cmap, truncating.
>>
>> I intend to remove all the dummy fonts from devpdf.
>
> I object. How would you solve problem articulated in "NEWS" instead?
>
Please explain the problem again. People can decide whatever naming convention
suits them.
The dummy fonts lie to groff about the glyphs available in the font. I
suspect the problem which this is trying to solve (nothing to do with naming
strategies) is to ring fence chinese, japanese, korean because CJK fonts tend
to cover all 3, but the correct place to do this is in the script you feed to
fontforge when converting to type 1 / type 42 for groff to use.
Since gropdf needs a real type 1 font in order to embed the glyphs in a pdf,
these dummy fonts will never work, and even grops needs ghostscript to supply
the actual font glyphs.
> I ask that we avoid having one solution for gropdf and a different one
> for grops and grotty, or worse, a different solution for every output
> driver.
Utf8 and html work, of course (they worked already with .ft TR etc.).
Dvi produces a corrupt file. Ps causes a blank page and ghostscript gives a
weird warning and outputs gobbledy-gook. X100 and X75 do not have the dummy
fonts. I don't see any consistency here. pdf should be the same as X100 and
X75, since it is not possible to do what grops does - rely on downstream to
actually find and incorporate the appropriate fonts. As you know only the
base-14 fonts are permitted to not have their glyphs embedded in a pdf, if
you can suggest a way around this I would be grateful.
>> However, if you run a slightly modified (see dj-trans.mm) using a real
>> installed CJK font (in my case called GR) the results are as expected.
>
> That's the idea. I see your change.
>
> .ftr JPM GR
> .ftr CSS GR
>
> ...would (should) work just as well. Does that work for you?
Yes. But for noone else who does not have a suitable GR font. Perhaps the NEWS
file could elaborate a bit more about how to use these fonts with each device,
i.e. describe the actions required for each device and examples of how to get
it working. JPM (for grops) relies on the font "Ryumin-Light-UniJIS-UTF16-H"
be installed on the system, so directions on where to download a (free) copy
would be helpful. We have already had one user assume, from reading the NEWS
item, that CJK output will be available just by typing .ft JPM, it seems more
complex than that.
Grops should definitely work with Tadziu's changes, I'm not sure what the
problem is, of course it could be a bug in ghostscript which causes it to barf
at the grops postscript. I don't think Tadziu intended for the devps fonts he
supplied to be copied to devpdf as well.
> What are the CJK equivalents of families "T" and "H"? If they don't
> exist already, we have to invent them.
Gothic and Mincho.
>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67830>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
