On 1/16/19 9:22 PM, clipka wrote:
> Now implementing `text` objects via FreeType and prism primitives:
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.1
> 
> Some notes:
> 
...
> 
> - Performance has degraded a bit, but I'm willing to accept this for the 
> sake of extended functionality and easier maintenance.
> 

Hmm, I'm surprised some by this. Are your test character strings really 
short? In the existing text shape code all the characters ended up more 
or less as one huge glyph as you know. As the string to the text shape 
got large, performance slowed substantially. Your implementing 
internally as a union of prisms should address this shortcoming well - 
providing a lot of room for other code to slow without overall impact. 
Wonder... Is the prism object a lot slower than the text object was? 
(I've never compared)

> Also, render results differ in several ways:
> 
...
> 
> - POV-Ray v3.7 (haven't checked whether this has been fixed already) 

It is fixed in the current 3.8 master. You picked up - or made 
independently - a change quite like one Jérôme made in hgpovray. I know 
because that code change collided on a rebase in a text shape branch 
where I'd made similar updates. I vaguely remember doing some 
verification of the fix too, along with some prism fix - but... maybe / 
maybe not.

> 
> - (*) For normal TrueType fonts, that is. Based on the FreeType 
> documentation, I totally expect the new implementation to get this 
> wrong, and/or to mess up the "holes" (e.g. in characters like `o`), with 
> /some/ font file formats or even individual fonts. Please keep your eyes 
> peeled, I'm keen to get my hands on any such font specimens.

I have somewhere a crude test set up / scene collection I created when I 
did my text shape hacks. I'll put it on my list to run those.

Plus, IIRC, I saw font sites offering fonts in multiple formats. Might 
be we can turn up problems with holes / overlaps or whatever by running 
such format sets and comparing resultant images. I now have a pretty 
good semi-automated testing framework for that sort of scene to sceen 
image testing so shouldn't take too much to get something going - 
provided I'm right about the availability of fonts in multiple formats.

Good stuff Christoph!

However, first up for me is to rebase my branches to the current 3.8 
master with the updated parser so the solver/other personal branch 
testing I'm doing is running the updated parser too.

Bill P.

Post a reply to this message