POV-Ray : Newsgroups : povray.pov4.discussion.general : On povr's accidental text{cmap} capability. : Re: On povr's accidental text{cmap} capability. Server Time
24 Feb 2024 18:04:55 EST (-0500)
  Re: On povr's accidental text{cmap} capability.  
From: William F Pokorny
Date: 1 Apr 2023 14:05:50
Message: <6428727e$1@news.povray.org>
On 4/1/23 10:43, Bald Eagle wrote:
> Have you tried sorting out that diacritical mark issue we were having a while
> back?

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 
fly...

---
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.

Bill P.

(a) - For a long time I've kept an eye on 'clipper'. See: 
http://www.angusj.com/clipper2/Docs/Overview.htm


Post a reply to this message

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