On 4/3/23 21:51, William F Pokorny wrote:
> Attached is a render turning off all automatic bounding(a) in the povr 
> fork with -mb - which confirms this is indeed happening.

Update. Found and fixed two issues in the povr fork.

The first accounted for most of the problems where characters were made 
up of multiple sub-glyphs. It goes as far back as I checked - to v3.0 
source.

It's been the case that x & y offsets for the sub-glyphs, when of 
non-word (aka byte) size, have been read as uint_8 and not int8_t 
(signed char).

The unsigned values are used with a point offset method not supported in 
our code at all. The x & y int8_t (signed char) method is - and it's 
what all font's I checked use. The sometimes correct - and sometimes 
completely wild results - come more from not handling he twos complement 
representation correctly for the read values than having read bad values.

The second issue hits here and there and it is bounding. The bounding 
was sometimes too tight for the resulting, flattened point loop 
representation of the font.

I don't see a hard problem, say in not looking at all the points or 
something. I believe, rather it's that the curve sometimes bulges 
outside the least enclosing rectangles of point lists representing the 
contours making up the character.

I sized up the bounding x,y size a little and fixed all but the edge of 
one case. That one case looks to me like it needs 'too much' expansion. 
Leaving it to look at in more detail later.

There is one definite issue is that the umlaut accented characters are 
not rendered correctly in the FreeSerif.ttf font. No idea what is going 
on there - those characters look OK to me for that font in other utilities.

Test images attached.

Bill P.

Post a reply to this message

Attachments:
Download 'povrfontfixes.png' (265 KB)

Preview of image 'povrfontfixes.png'