On 4/1/23 10:43, Bald Eagle wrote:
> Have you tried sorting out that diacritical mark issue we were having a while
I did see the thread, but no.
Where the ring is incomplete at the top of the A in some fonts, I
strongly suspect overlapping polygon point lists - which are technically
legal - but the cleanest fonts eliminate such overlaps.
Those fonts represent the same covered areas with non-overlapping
polygons point lists - which you can always do.
POV-Ray cannot handle the overlaps a renders the even overlapped areas
as empty space. There isn't any fixing this beyond adopting some polygon
processing package(a) to create non-overlapping representations on the
Some of the rest I suspect is a font not implementing a character as a
single glyph, but as an assembly of glyphs - to save space. A guess is
that POV-Ray tried and failed to position all the parts of some assembly
correctly in some of those funky cases. (Parts / point loops ending up
outside the per prism bounding within the overall union of objects - in
addition to - or as part of being placed incorrectly)
In the end POV-Ray is not a word processor or type setting application -
and should never be in my opinion. There are significant packages for
such work like freetype and IBM's open source ICT
(https://icu.unicode.org/) underneath much of the font handling we "see"
in applications. POV-Ray will likely use such libraries to make font
handling better at some point, but I'd bet big there will always be
things that don't quite work.
Aside: I've thought about what POV-Ray might look like with single
character, ready made polygon representations in include libraries with
no inbuilt text object at all. Rather SDL code to position characters in
a string. Suppose that too is no small amount of work... It's attractive
as an end goal in that it would get the POV-Ray core code out of the
font handling game.
(a) - For a long time I've kept an eye on 'clipper'. See:
Post a reply to this message