POV-Ray : Newsgroups : povray.general : Fonts Rant Server Time
28 Mar 2024 05:31:57 EDT (-0400)
  Fonts Rant (Message 5 to 14 of 21)  
<<< Previous 4 Messages Goto Latest 10 Messages Next 7 Messages >>>
From: Le Forgeron
Subject: Re: Fonts Rant
Date: 11 Jan 2019 11:17:08
Message: <5c38c184@news.povray.org>
Le 11/01/2019 à 14:57, clipka a écrit :
> Am 11.01.2019 um 09:10 schrieb Thorsten Froehlich:
>> I can tell you how this former German developer solved it: The claasic
>> Mac
>> version used to have special code to extract Mac Roman fonts from the
>> system...
> 
> I intend to do that for the Windows version, too.
> 
> But I think we should have some baseline collection of fonts (if only
> for the Benchmark scene), and I'd like them to be at least reasonably
> ok. It's not like there aren't any free fonts out there we could "adopt".

Seconded.

We need a Serif, a Sans Serif and a Mono spaced, IMHO.

And good looking ones, with latin-1 page and other cool stuff.

As long as only 16 bits are parsed, the chinese glyphes are out of scope.


Post a reply to this message

From: clipka
Subject: Re: Fonts Rant
Date: 12 Jan 2019 09:05:15
Message: <5c39f41b$1@news.povray.org>
Am 11.01.2019 um 17:17 schrieb Le_Forgeron:

> We need a Serif, a Sans Serif and a Mono spaced, IMHO.

Agreed.

> And good looking ones, with latin-1 page and other cool stuff.

Sure.

> As long as only 16 bits are parsed, the chinese glyphes are out of scope.

No, they're not. Not the most important ones at any rate: Roughly 30k 
CJK ideographs are assigned to the Basic Multilingual Plane.

We will of course miss out on the approx. 60k /additional/ CJK 
ideographs in Plane 2. Also, no Phoenician, Egyptian Hieroglyphs, 
Cuneiform or the like (Plane 1).


Post a reply to this message

From: clipka
Subject: Re: Fonts Rant
Date: 14 Jan 2019 22:29:58
Message: <5c3d53b6$1@news.povray.org>
Am 11.01.2019 um 04:01 schrieb clipka:

> Also, I have decided to try changing the font handling from our own 
> dated code to using the FreeType library. That way I won't be tempted to 
> work around such crap. Them old fonts no longer work? Tough luck. If the 
> lib won't handle them, then maybe, just maybe, the fonts really are the 
> pieces of shit I'm calling them.

Work is progressing. And it looks like I'll be ripping out the text 
primitive entirely.


Well, /almost/ entirely that is. The parser will still understand the 
`text` syntax. But instead of implementing it via a dedicated geometric 
shape it will map it to a union of `prism` objects. (Theoretically a 
single `prism` object would do in typical cases, but turns out to be 
noticeably inferior in terms of performance.)

Under the hood, the text primitive has essentially been duplicating 
prism functionality all along, except that it is limited to 2rd order 
splines. While that provides some benefits in terms of performance, it 
also means it's not up-to-date to team up with the FreeType library, 
which supports various non-TrueType font file formats, including some 
which are based on 3rd order splines.

So rather than investing any time and effort into refurbishing the 
somewhat redundant text primitive, I've instead invested some time and 
effort to see if it can be replaced with the prism primitive entirely. 
So far it seems as easy as eating pancakes.


Post a reply to this message

From: ingo
Subject: Re: Fonts Rant
Date: 15 Jan 2019 01:38:29
Message: <XnsA9D84DBB7B739seed7@news.povray.org>
in news:5c3d53b6$1@news.povray.org clipka wrote:

> So far it seems as easy as eating pancakes.

Would it also be possible to make the fonts avalable as splines? Thinking 
of spheresweeps, sweeping spheres, lofting and extruding mesh's,

ingo


Post a reply to this message

From: William F Pokorny
Subject: Re: Fonts Rant
Date: 15 Jan 2019 06:29:34
Message: <5c3dc41e$1@news.povray.org>
On 1/14/19 10:29 PM, clipka wrote:
> Am 11.01.2019 um 04:01 schrieb clipka:
> 
>> Also, I have decided to try changing the font handling from our own 
>> dated code to using the FreeType library. That way I won't be tempted 
>> to work around such crap. Them old fonts no longer work? Tough luck. 
>> If the lib won't handle them, then maybe, just maybe, the fonts really 
>> are the pieces of shit I'm calling them.
> 
> Work is progressing. And it looks like I'll be ripping out the text 
> primitive entirely.
> 
> 
> Well, /almost/ entirely that is. The parser will still understand the 
> `text` syntax. But instead of implementing it via a dedicated geometric 
> shape it will map it to a union of `prism` objects. (Theoretically a 
> single `prism` object would do in typical cases, but turns out to be 
> noticeably inferior in terms of performance.)
> 
> Under the hood, the text primitive has essentially been duplicating 
> prism functionality all along, except that it is limited to 2rd order 
> splines. While that provides some benefits in terms of performance, it 
> also means it's not up-to-date to team up with the FreeType library, 
> which supports various non-TrueType font file formats, including some 
> which are based on 3rd order splines.
> 
> So rather than investing any time and effort into refurbishing the 
> somewhat redundant text primitive, I've instead invested some time and 
> effort to see if it can be replaced with the prism primitive entirely. 
> So far it seems as easy as eating pancakes.

And no doubt less sticky. :-)

While updating the text primitive, are you giving any thought to right 
to left and vertical syntax in addition to the existing left to right?

Aside: My recollection from looking at the text object back when I was 
playing with the hard and soft objects is that certain font-encodings 
support overlapping polygon regions by being strict about the 2d winding 
order of the path outlines for the definition of inside and outside as 
opposed to the crossing test we use. Perhaps some kind of crossing test 
compatible normalization is necessary if supporting what FreeType 
supports? Perhaps too an issue for later as I have no idea how common 
overlapped encoding is...

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Fonts Rant
Date: 15 Jan 2019 07:11:54
Message: <5c3dce0a$1@news.povray.org>
On 1/15/19 1:38 AM, ingo wrote:
> in news:5c3d53b6$1@news.povray.org clipka wrote:
> 
>> So far it seems as easy as eating pancakes.
> 
> Would it also be possible to make the fonts avalable as splines? Thinking
> of spheresweeps, sweeping spheres, lofting and extruding mesh's,
> 
> ingo
> 

Supposing you know font splines are outline/edge based so some extra 
processing would be needed for a stroke spline as might come from a 
mouse or tablet.

Are you asking for the font splines as is or as variable width pen 
strokes say?

Aside:
-----
During a crazy few days a couple years ago I made a serious start on 
software for creating a POV-Ray library (spheresweep like def) 
equivalent of the GNU Unifont:

https://en.wikipedia.org/wiki/GNU_Unifont

The idea was to create some initial set of centered linear bezier 
segments - with start/end width spec - from the Unifont/other open 
source mono-spaced fonts with some automation and then refine it over time.

The thought was to have available a centered spline definition of high 
resolution which might be much more useful to folks than the Unifont is. 
In creating other fonts, doing character recognition or whatever. 
POV-Ray as an actual font editor/analyzer of sorts, I guess, working 
from an initial Unifont-like POV-Ray compatible center-line stroke 
database.

I am, on odd and even days, not that sane.

Bill P.


Post a reply to this message

From: ingo
Subject: Re: Fonts Rant
Date: 15 Jan 2019 08:05:23
Message: <XnsA9D88F544360Aseed7@news.povray.org>
in news:5c3dce0a$1@news.povray.org William F Pokorny wrote:

> Are you asking for the font splines as is or as variable width pen 
> strokes say?
>

Just the (outline)splines as is.

Moving blobs along a spline with a threshold depending on the 'speed' could give an
impression of a 
stroke. Iirc Inkscape can be used to extract a spline from a font for some
experiments.

Capping an object or mesh from such a spline will probably be a bit more probalamatic,
but we 
always have the prism.

>[...]
> 
> I am, on odd and even days, not that sane.
> 

Cherish that Bill!

ingo


Post a reply to this message

From: ingo
Subject: Re: Fonts Rant
Date: 15 Jan 2019 08:44:00
Message: <XnsA9D895E03D406seed7@news.povray.org>
in news:XnsA9D88F544360Aseed7@news.povray.org ingo wrote:

> Iirc Inkscape can be used to extract a spline from a font for some
> experiments. 

:( that results in a Bezier spline we do not have as a spline ...

ingo


Post a reply to this message

From: clipka
Subject: Re: Fonts Rant
Date: 15 Jan 2019 15:12:30
Message: <5c3e3eae$1@news.povray.org>
Am 15.01.2019 um 07:38 schrieb ingo:
> Would it also be possible to make the fonts avalable as splines? Thinking
> of spheresweeps, sweeping spheres, lofting and extruding mesh's,

Technically that should certainly be possible - with some limitations 
though. Most notably, I expect such splines to be useless in animations, 
as the "time" values would presumably be arbitrary and unrelated to the 
actual length of the individual spline segments.


As an aside, the FreeType library also supports some font formats that 
are stroke-based rather than outline-based.

As for Bezier splines, it is a shame we don't have a common consistent 
spline framework across all spline-based features, and if I (or someone 
else?) ever find the time I hope that will change.


Post a reply to this message

From: clipka
Subject: Re: Fonts Rant
Date: 15 Jan 2019 16:14:54
Message: <5c3e4d4e$1@news.povray.org>
Am 15.01.2019 um 12:29 schrieb William F Pokorny:

>> So rather than investing any time and effort into refurbishing the 
>> somewhat redundant text primitive, I've instead invested some time and 
>> effort to see if it can be replaced with the prism primitive entirely. 
>> So far it seems as easy as eating pancakes.
> 
> And no doubt less sticky. :-)

If you're thinking of New England style pancaces, with maple syrup, then 
yes, most certainly ;)


> While updating the text primitive, are you giving any thought to right 
> to left and vertical syntax in addition to the existing left to right?

Yes, no and yes.

Yes, I did give some thought not only to left/right/vertical writing 
systems, but other text layout considerations as well, such as 
ligatures, scripts where the same character may have different shapes 
depending on context, Unicode variation sequences, or Unicode composite 
characters, and decided that I'll eventually want support for all of 
that in the `text` "primitive"

No, I decided to not implement any of that now.

Before deciding to go for FreeType, I had a look at HarfBuzz, but as it 
turns out it apparently requires FreeType as well, so I decided to aim 
low for now and use only FreeType, with the intent of adding HarfBuzz later.

Yes, I decided to structure the code in such a way that adding all those 
bells and whistles later should be relatively easy.

Most notably, I'm structuring the code into two distinct steps: Step 1 
will decide which glyphs to use and where to place them, while step 2 
will retrieve the corresponding glyph outlines and convert them to prism 
control points.

Right now FreeType will be used for both steps 1 and 2, with step 1 
being limited to a straightforward mapping of UCS code points to the 
corresponding "canonical" glyphs and simple left-to-right placement with 
kerning as the only "fancy" feature.

In the future, step 2 will presumably remain the domain of FreeType, but 
step 1 might be extended or even completely rewritten to provide more 
bells & whistles. One such extension might be the addition of bidi 
support, e.g. via fribidi, while another one might be the addition of 
full-fledged /text shaping/, e.g, via HarfBuzz.


> Aside: My recollection from looking at the text object back when I was 
> playing with the hard and soft objects is that certain font-encodings 
> support overlapping polygon regions by being strict about the 2d winding 
> order of the path outlines for the definition of inside and outside as 
> opposed to the crossing test we use. Perhaps some kind of crossing test 
> compatible normalization is necessary if supporting what FreeType 
> supports? Perhaps too an issue for later as I have no idea how common 
> overlapped encoding is...

I am aware of this category of issues, but intend to address them as 
they come up, and no sooner. Right now I'm happy that the default 
behaviour exhibited by the prism object seems to perfectly match the 
most commonly used fill mode.


Post a reply to this message

<<< Previous 4 Messages Goto Latest 10 Messages Next 7 Messages >>>

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