POV-Ray : Newsgroups : povray.general : Fonts Rant : Re: Fonts Rant Server Time
19 Apr 2024 15:41:40 EDT (-0400)
  Re: Fonts Rant  
From: William F Pokorny
Date: 15 Jan 2019 06:29:34
Message: <5c3dc41e$1@news.povray.org>
On 1/14/19 10:29 PM, clipka wrote:
> Am 11.01.2019 um 04:01 schrieb clipka:
> 
>> Also, I have decided to try changing the font handling from our own 
>> dated code to using the FreeType library. That way I won't be tempted 
>> to work around such crap. Them old fonts no longer work? Tough luck. 
>> If the lib won't handle them, then maybe, just maybe, the fonts really 
>> are the pieces of shit I'm calling them.
> 
> Work is progressing. And it looks like I'll be ripping out the text 
> primitive entirely.
> 
> 
> Well, /almost/ entirely that is. The parser will still understand the 
> `text` syntax. But instead of implementing it via a dedicated geometric 
> shape it will map it to a union of `prism` objects. (Theoretically a 
> single `prism` object would do in typical cases, but turns out to be 
> noticeably inferior in terms of performance.)
> 
> Under the hood, the text primitive has essentially been duplicating 
> prism functionality all along, except that it is limited to 2rd order 
> splines. While that provides some benefits in terms of performance, it 
> also means it's not up-to-date to team up with the FreeType library, 
> which supports various non-TrueType font file formats, including some 
> which are based on 3rd order splines.
> 
> So rather than investing any time and effort into refurbishing the 
> somewhat redundant text primitive, I've instead invested some time and 
> effort to see if it can be replaced with the prism primitive entirely. 
> So far it seems as easy as eating pancakes.

And no doubt less sticky. :-)

While updating the text primitive, are you giving any thought to right 
to left and vertical syntax in addition to the existing left to right?

Aside: My recollection from looking at the text object back when I was 
playing with the hard and soft objects is that certain font-encodings 
support overlapping polygon regions by being strict about the 2d winding 
order of the path outlines for the definition of inside and outside as 
opposed to the crossing test we use. Perhaps some kind of crossing test 
compatible normalization is necessary if supporting what FreeType 
supports? Perhaps too an issue for later as I have no idea how common 
overlapped encoding is...

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.