Am 29.07.2021 um 10:35 schrieb jr:

>>> also, while on 'povr', I
>>> ran into trouble viewing font glyphs >= chr(256).
>>
>> True my text{} isn't POV-Ray's exactly... Is this something unique to
>> the povr branch? Off the top of my head, this likely normal unless using
>> a unicode string specifications.
> 
> not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
> 'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
> output.

povr is based on those rolled-back alpha versions, right? Then color me 
unsurprised.

Did I ever, maybe in passing, mention that POV-Ray v3.7's behavior 
(which we strive to emulate in v3.8) regarding non-ASCII characters and 
fonts is seriously borked?


> also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
> display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
> yet checked to find out why (have to install one or two of the fonts first).

It is theoretically possible for fonts to provide a non-empty glyph for 
the ASCII "space" character. I guess this could go unnoticed in most 
programs, as they would typically use operating systems calls to render 
text, which in turn could conveivably give special treatment to ASCII 
"space" by simply inserting a gap according to the character's width.

I think POV-Ray does not currently do that, and instead treats "space" 
like any other character, i.e. it may or may not have a visible glyph.


But I think we're digressing a bit from the original thread...

Post a reply to this message