POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10 : Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10 Server Time
21 Jun 2024 00:54:30 EDT (-0400)
  Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10  
From: William F Pokorny
Date: 28 Jul 2021 15:34:17
Message: <6101b139@news.povray.org>
On 7/28/21 11:38 AM, jr wrote:
> hi,
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> because the default format strings has a 'Z' on the end where I suspect
>> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
>> time offset more general.
>>    v3.8 (povr) default -> 2021-07-28 08:15:15 -0400
> is this new?  because does not work for me, see below.  

Relatively, I guess. Looks like I updated this with a commit on:

Date:   Fri Jun 11 06:18:44 2021 -0400

where I changed datetime() to optionally generate a time accounting for 
the local daylight savings time datetime(-100000) after getting myself 
tangled up due the generated datetime() string not aligning to my local 
-dst adjusted - computer time. Only %z %Z appear to be dst aware with 
datetime() otherwise.

So... The Z to ' %z' is an update not yet published.

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


In povr, I'm leaning in a direction of eliminating the text{} object... 
Or, at least, not further updating it.

Christoph has been playing with freetype and making the text{} internals 
prisms as you know. I'm thinking perhaps all characters/glyphs should 
just be include-able objects only where we'd use SDL macros to do all 
the placements for a string -- get POV-Ray, at the core, completely out 
of the text formatting game and push that sort of thing into SDL.

If you look at the text oriented macros shipped today - like 
Circle_Text(), for example, they are actually doing a lot of work to 
pull apart text{} strings character by character. When I do isosurface 
stuff with text{} strings, I often do the same to get to single 
'characters' for better performance. Effectively, pulling text{} objects 
apart - or internally doing this - for most work is a painfully 
backwards way to approach things in my opinion.

Bill P.

Post a reply to this message

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