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