POV-Ray : Newsgroups : povray.binaries.images : Borked diacritical marks Server Time
15 Jul 2024 19:38:23 EDT (-0400)
  Borked diacritical marks (Message 8 to 17 of 17)  
<<< Previous 7 Messages Goto Initial 10 Messages
From: Alain Martel
Subject: Re: Borked diacritical marks
Date: 31 Jan 2023 11:36:31
Message: <63d9438f$1@news.povray.org>
Le 2023-01-30 à 20:17, Kenneth a écrit :
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>   (sorry, I hit the 'send message' button too early by mistake)
>>>
>>> Doing another test, I've discovered that the web-portal 'editor' for writing
>>> posts is where the problem lies-- it wipes out the sentence before sending it,
>>> when the "Preview Message" button is pressed.
>>
>> The line may either still be there, and only visible in the newsreader (like
>> Thunderbird), or you have to post it with a newsreader, and then it works.
>>
> 
> I was wondering the same thing. I would imagine that I would have to use a
> newsreader to *send* it, since the line disappears on my end before it's
> actually sent.
> 
> A test:
> The following sentence has a special character in one of the words. If you can
> see it in Thunderbird, that would be useful to know. I will not see it using the
> web portal, once it is posted:
> 
> This sentence uses the word exposé.
> 
> 
> 
Everything show up correctly. Viewed in Thunderbird.


Post a reply to this message

From: Kenneth
Subject: Re: Borked diacritical marks
Date: 31 Jan 2023 13:10:00
Message: <web.63d958a3b78816609b4924336e066e29@news.povray.org>
Alain Martel <kua### [at] videotronca> wrote:
> >
> > A test:
> > The following sentence has a special character in one of the words...
> >


> >
> Everything show up correctly. Viewed in Thunderbird.

Thanks! It seems that the problem is only with the newsgroups' web-portal and
message editor.


Post a reply to this message

From: William F Pokorny
Subject: Re: Borked diacritical marks
Date: 3 Apr 2023 08:33:16
Message: <642ac78c$1@news.povray.org>
On 1/22/23 11:57, Cousin Ricky wrote:
> After looking at tx2378's problem ("bad display of utf8 code u00ed
> letter i-accute in times new roman" in p.programming) and becoming
> increasingly confused by what POV-Ray is doing, I rendered a suite of
> Latin-1 accented characters with various fonts.  The results are
> bafflingly inconsistent:

In a thread about povr/v4.0's cmap{} code changes, Bald Eagle asked me 
if I'd dug into this issue. I'd not - though I had some guesses as to 
what might be wrong.

Well, I'm going to take a run at this issue. Due cmap{} I got some light 
exposure to several unix/linux font utilities. Plus I'll be busy with 
real life over the next couple months and this work the right sort to 
fit here and there as time allows.

I created a test case(a) to see if I could turn up some similar issues 
with linux Ubuntu shipped fonts. The first I tried in FreeMono.ttf fails 
wonderfully! Plenty of issues when Rendered in POV-Ray(povr). :-)

Aside: I can see already there are two tables in the working DejaVuSans 
not in the FreeMono. I have no idea at the moment if that affects anything.

Bill P.

(a) - Yep. The acute lower case i (í) was wrong.


Post a reply to this message


Attachments:
Download 'accentedvowelsstory.png' (32 KB)

Preview of image 'accentedvowelsstory.png'
accentedvowelsstory.png


 

From: William F Pokorny
Subject: Re: Borked diacritical marks
Date: 3 Apr 2023 21:51:03
Message: <642b8287$1@news.povray.org>
On 4/3/23 08:33, William F Pokorny wrote:
> Bald Eagle asked me if I'd dug into this issue. I'd not - though I had 
> some guesses as to what might be wrong.

One of those guesses was that the marks were all present, but not 
correctly placed. Meaning they were getting cut off by the automatic 
bounding for each character.

Attached is a render turning off all automatic bounding(a) in the povr 
fork with -mb - which confirms this is indeed happening.

Bill P.

(a) - The -mb option here fully works only in povr where the v3.6 and 
prior '-mb' behavior was restored.

You can use -mb in official v3.7, v3.8 and v4.0 releases, but it no 
longer turns off the very last level of bounding around an object.


Post a reply to this message


Attachments:
Download 'accentedvowels_bndsoff.png' (39 KB)

Preview of image 'accentedvowels_bndsoff.png'
accentedvowels_bndsoff.png


 

From: William F Pokorny
Subject: Re: Borked diacritical marks
Date: 5 Apr 2023 04:38:21
Message: <642d337d$1@news.povray.org>
On 4/3/23 21:51, William F Pokorny wrote:
> Attached is a render turning off all automatic bounding(a) in the povr 
> fork with -mb - which confirms this is indeed happening.

Update. Found and fixed two issues in the povr fork.

The first accounted for most of the problems where characters were made 
up of multiple sub-glyphs. It goes as far back as I checked - to v3.0 
source.

It's been the case that x & y offsets for the sub-glyphs, when of 
non-word (aka byte) size, have been read as uint_8 and not int8_t 
(signed char).

The unsigned values are used with a point offset method not supported in 
our code at all. The x & y int8_t (signed char) method is - and it's 
what all font's I checked use. The sometimes correct - and sometimes 
completely wild results - come more from not handling he twos complement 
representation correctly for the read values than having read bad values.

The second issue hits here and there and it is bounding. The bounding 
was sometimes too tight for the resulting, flattened point loop 
representation of the font.

I don't see a hard problem, say in not looking at all the points or 
something. I believe, rather it's that the curve sometimes bulges 
outside the least enclosing rectangles of point lists representing the 
contours making up the character.

I sized up the bounding x,y size a little and fixed all but the edge of 
one case. That one case looks to me like it needs 'too much' expansion. 
Leaving it to look at in more detail later.

There is one definite issue is that the umlaut accented characters are 
not rendered correctly in the FreeSerif.ttf font. No idea what is going 
on there - those characters look OK to me for that font in other utilities.

Test images attached.

Bill P.


Post a reply to this message


Attachments:
Download 'povrfontfixes.png' (265 KB)

Preview of image 'povrfontfixes.png'
povrfontfixes.png


 

From: Bald Eagle
Subject: Re: Borked diacritical marks
Date: 5 Apr 2023 06:35:00
Message: <web.642d4e9ab78816601f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> The unsigned values are used with a point offset method not supported in
> our code at all. The x & y int8_t (signed char) method is - and it's
> what all font's I checked use. The sometimes correct - and sometimes
> completely wild results - come more from not handling he twos complement
> representation correctly for the read values than having read bad values.

Nice catch.  That certainly accounts for the wild placement, whereas bounding
was just an incidental problem.

Now that you've stuck your head deep into the glyph-handling code, how difficult
would you say it would be to write code in SDL that would take a font file and
create splines and/or prisms?

Or make the internal conversion exposed to SDL so that the result could be
written to a file?

Nice work   :)

- BW


Post a reply to this message

From: William F Pokorny
Subject: Re: Borked diacritical marks
Date: 6 Apr 2023 01:55:39
Message: <642e5edb@news.povray.org>
On 4/5/23 06:34, Bald Eagle wrote:
> Now that you've stuck your head deep into the glyph-handling code, how difficult
> would you say it would be to write code in SDL that would take a font file and
> create splines and/or prisms?

That is what text{} does - more or less. You just don't see the result 
is a union of a bunch of prisms (one per character) - where 'nested' 
splines making up a character have been flattened.

> 
> Or make the internal conversion exposed to SDL so that the result could be
> written to a file?

I thought about capturing the result too, and as a complete code hack, 
not too bad to do.

Really supporting such a thing in SDL, much harder for sure. I doubt 
worth it, but not thought much about performance differences, for example.

There are a large number of font tools out there which can do things 
like dump particular glyphs. It's probably not too hard to create 
something base on one of those too utilities too.

> 
> Nice work   😄

Thanks.

Oh, I sorted that FreeSerif.ttf umlaut issue - 'twas me having left some 
hacked code in place.

I've been playing with other fonts and symbols as a way to test a bit 
more. Looking good thus. You do realize somewhat quickly there are 
gazillions of free-ish fonts out there, but most cover only a small 
number of Unicode character space. Anyhow. Attached another example 
image - of some symbols this time.

One thing not working (and not expected to) is anything outside the 
Basic Multilingual Plane (BMP). I pushed there a little - and it's all 
crash, boom, bang at the moment.

Bill P.


Post a reply to this message


Attachments:
Download 'miscsymbols3.png' (308 KB)

Preview of image 'miscsymbols3.png'
miscsymbols3.png


 

From: Cousin Ricky
Subject: Re: Borked diacritical marks
Date: 6 Apr 2023 14:17:45
Message: <642f0cc9$1@news.povray.org>
On 2023-04-05 04:38 (-4), William F Pokorny wrote:
> On 4/3/23 21:51, William F Pokorny wrote:
>> Attached is a render turning off all automatic bounding(a) in the povr
>> fork with -mb - which confirms this is indeed happening.
> 
> Update. Found and fixed two issues in the povr fork.

Any chance of pulling these changes into POV-Ray 3.8?


Post a reply to this message

From: Bald Eagle
Subject: Re: Borked diacritical marks
Date: 6 Apr 2023 14:40:00
Message: <web.642f10d7b78816601f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/5/23 06:34, Bald Eagle wrote:
> > Now that you've stuck your head deep into the glyph-handling code, how difficult
> > would you say it would be to write code in SDL that would take a font file and
> > create splines and/or prisms?
>
> That is what text{} does - more or less. You just don't see the result
> is a union of a bunch of prisms (one per character) - where 'nested'
> splines making up a character have been flattened.
>
> >
> > Or make the internal conversion exposed to SDL so that the result could be
> > written to a file?
>
> I thought about capturing the result too, and as a complete code hack,
> not too bad to do.
>
> Really supporting such a thing in SDL, much harder for sure. I doubt
> worth it, but not thought much about performance differences, for example.

I was sort of thinking about this as an infrequently used tool to export the
splines/prisms to an include file.

Currently, Cousin Ricky and I have resorted to using spreadsheets to convert
font files to splines.  If the extant source code could be easily "fixed" to
remove any C/C++ tricky coding stuff, then I'm sure the rest of us could take it
from there and convert the rest of the C/C++ syntax to SDL to make a nice
include file that could take a font filename as an argument and write out a
series of objects as splines and prisms.

I also look at things like that as a great instructional/learning tool for
people to understand how things happen under the hood, and maybe enough dots get
connected where we have people want to step up to do development work.

(Also, IIRC, since the STL file format is virtually a clone of POV-Ray's
mesh/triangle syntax, it would be fantastic if that geometry could be read from
the file directly without conversion.  Even if it were an experimental feature
that didn't do everything perfectly, it would still be a start, and a handy tool
for importing those kinds of meshes into scenes.)

- BW


Post a reply to this message

From: William F Pokorny
Subject: Re: Borked diacritical marks
Date: 6 Apr 2023 17:09:32
Message: <642f350c$1@news.povray.org>
On 4/6/23 14:17, Cousin Ricky wrote:
> On 2023-04-05 04:38 (-4), William F Pokorny wrote:
>> On 4/3/23 21:51, William F Pokorny wrote:
>>> Attached is a render turning off all automatic bounding(a) in the povr
>>> fork with -mb - which confirms this is indeed happening.
>>
>> Update. Found and fixed two issues in the povr fork.
> 
> Any chance of pulling these changes into POV-Ray 3.8?
> 

In this case I think my code changes could be pulled directly into the 
v3.8 code base, but it's not something I tried or tested.

See:

http://news.povray.org/povray.beta-test/message/%3C642f33e8%241%40news.povray.org%3E/

or

Message: <642f33e8$1@news.povray.org>

Bill P.


Post a reply to this message

<<< Previous 7 Messages Goto Initial 10 Messages

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