[gs-devel] Type42 FontBBox ignored

[Chris Liddell]

On 31/05/2021 05:09, David Newall wrote:
> I'm trying to change the line height for a font by redefining FontBBox
> using the following code:
> 
>     /RedefinedFont /OriginalFont findfont dup length dict begin
>     	{ 1 index /FID ne 2 index /UniqueID ne and 2 index /XUID ne and {def} {pop pop} ifelse } forall
>     	[(Original FontBBox)/FontBBox load]==
>     	/FontBBox [ /FontBBox load aload pop dup dup 5 -1 roll sub 1.3 mul sub 3 1 roll ] def % increase line height by 30%
>     	[(Redefined FontBBox)/FontBBox load]==
>     	/FontName 1 index def
>     	currentdict
>     end definefont
>     [(Stored FontBBox)/RedefinedFont findfont /FontBBox get]==
> 
> This works with a type 42 font embedded in the PostScript that I send to
> a PS printer (HP 9050) but not using GhostScript  9.26 on Ubuntu 16.04.
> 
> FontBBox is correctly recalculated but the original FontBBox is restored
> after definefont.  For example, having re-encoded NimbusRoman-Regular as
> type 42 using FontForge, I get the following trace output:
> 
>     [(Original FontBBox) {-0.168 -0.281 1.0 1.053}]
>     [(redefined FontBBox) [-0.168 -0.681199908 1.0 1.053]]
>     [(Stored FontBBox) [-0.168 -0.281 1.0 1.053]]
> 
> Note that the type of FontBBox has been changed from an executable
> array, which is consistent with how I redefined it, but the values are
> the original ones.
> 
> If I remove FontBBox from the type 42 definition, the dictionary
> returned by findfont has no FontBBox, as one would expect.  If there is
> a FontBBox, it doesn't, no matter what values are given in the original
> definition, the result of definefont always uses recalculated values.
> 
> Obviously I can work around this by only using type 1 fonts but I'd
> really like it to work as expected with type 42.
> 

It does appear that we "refine" the font bbox in at least some
circumstances - frankly, I've no clear idea why.

TBH, most code that does something like what you need will scale the
font to suit - at most, change the FontBBox might change how glyphs are
clipped. So I assume you have "later" code that calculates y-offsets
based on the values in the FontBBox.


Anyway, I would at least like to know why we do that "refining" of the
FontBBox and I can't look at it right now so, to ensure I don't forget,
I'd appreciate it if you could open a bug here:

https://bugs.ghostscript.com/

And make the "Product" Ghostscript and "Component" "Font API", please
also include a gs command line, and an input file that illustrates the
problem (and symptom of the problem, if possible).

Thanks,

Chris