Hello again,

At the moment, if we have OTF-only fonts, we have to convert them to TTF. It's a
long work to do when using big font families having
Regular/Bold/Italic/Bold-Italic/... plus condensed versions plus wide versions
plus... plus... 8P

It would be so nicer if povray could simply support at least OTF fonts too.
( You could ever try to use the freetype library to do so ? ← If it could
help )

Thank you.

Post a reply to this message

Am 21.02.2021 um 21:28 schrieb zebulon 1er:

> At the moment, if we have OTF-only fonts, we have to convert them to TTF. It's a
> long work to do when using big font families having
> Regular/Bold/Italic/Bold-Italic/... plus condensed versions plus wide versions
> plus... plus... 8P
> 
> It would be so nicer if povray could simply support at least OTF fonts too.
> ( You could ever try to use the freetype library to do so ? ← If it could
> help )


I had actually started work on exactly that back in early 2019. I think 
the code hasn't made it into POV-Ray proper yet, but it is there in the 
official POV-Ray repo, as the `experimental/freetype` branch, and the 
`v3.8.0-x.freetype` series of binaries 
(https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.3).

I'd have to take a closer look again to see what the last status of the 
code was, but IIRC it already supported PS-style OpenType fonts (in 
addition to TrueType fonts and TT-style OpenType fonts). Or actually any 
outline font supported by the FreeType library.

IIRC there were some issues with fringe cases, in which the render 
result would differ from POV-Ray's old proprietary TT handling, but that 
was a bullet that I considered worth biting.


(The render differences have their roots in the fact that 
PostScript-style fonts differ fundamentally from TrueType-style fonts, 
in that they use spline outlines of 3rd order rather than just 2nd 
order. Even with FreeType there would be no sane way to translate
PS-style fonts into the form the old `text` primitive core code needs. 
However, the `prism` primitive does pretty much exactly the same job, 
and is already well equipped to handle 3rd order splines. So in the 
experimental branch mentioned above, all the `text` primitive handling 
has been stripped out entirely, except for a bit of code in the parser 
that now secretly just translates any `text` objects into corresponding 
`prism` primitives, interfacing to the FreeType library for the glyph 
outline details. The caveat is that the old `text` primitive, while 
having been very similar in functionality to the `prism` primitive for 
2nd order splines, behaved slightly different in certain situations.)

Post a reply to this message