bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #66323] [gropdf] rendering differences between PostScript and PDF o


From: G. Branden Robinson
Subject: [bug #66323] [gropdf] rendering differences between PostScript and PDF output?
Date: Thu, 17 Oct 2024 08:31:32 -0400 (EDT)

Follow-up Comment #32, bug #66323 (group groff):

At 2024-10-14T16:54:11-0400, Deri James wrote:
> Follow-up Comment #18, bug #66323 (group groff):
> > >   pdfmom -Kutf8 -P-e good-clean.mom > good-clean.pdf
> > > along with their respective ps and pdf files.  The family 
> > > is T, not U-T, because the URW fonts are not, by default, in 
> > > font/devps.  (Why?)
> 
> > Deri's been asking me that for a long time and I no longer remember
> > the answer.  Something was difficult about it.  Maybe I wouldn't
> > find it so anymore.
> 
> Using afmtodit to generate new groff fonts from current versions of
> the URW fonts yields a magnitude more kern pairs than our current
> stock 35 fonts, which means all documents will render differently
> after the new fonts installed (tighter text because a lot more
> kerning).

Ahh, thanks for clearing this up.  My memory was pretty muddled.

> One solution is we retire our current fonts to an oldfont-1.23.0
> directory and generate new fonts for devps, which would mean people
> could use -F to restore the old font behaviour.  As well as more
> kerning, there is significantly more glyph coverage as well, which may
> be a problem.  grops does not embed any of the 35 standard fonts in
> its postscript, it relies on the fact that all postscript printers
> would have a rom containing the 35 fonts in order for adobe to allow
> it to be called a "postscript printer".  Would these roms hold more
> than the 256 standard glyphs, unlikely if we are talking about a 30 yr
> old apple laser writer.  grops can of course embed fonts in the
> postscript, so grops could be given an -e flag (like gropdf) which
> tells it to embed all fonts.  This would require a suitable download
> file.

Most of the above prospect doesn't excite me, except for a new grops
`-e` flag that would behave in parity with gropdf's (including a new
default of embedding all fonts, as noted in bug #66342).

> Another would be to extend the foundry solution and add a -y flag to
> groff so with -yU when it processed .ft TR it would go looking for
> U-TR and .fam T would be understood as U-T.  This means either set of
> fonts can be used by the same roff doc.

In case I haven't said it before (or recently), I think this is a good
idea.  But I didn't officially record that opinion in Savannah, it
seems, so I've filed it as bug #66344.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66323>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]