search

w3c / font-text-cg

GitHub Pages
https://w3c.github.io/font-text-cg/
Other
28 stars 5 forks source link

Shaping arbitrary Ideographic Description Sequences #33

Open ctrlcctrlv opened 4 years ago

ctrlcctrlv commented 4 years ago

Dedicated issue split from stalled proposals list, was #9 item №6.

Document (version 1)

mpsuzuki commented 4 years ago

I think there would be 2 basic items to set the goal.

  1. The number of the sequences to be supported by single font file? 10 or so? 100 or so? 1000 or so?

  2. The proposal would request new shaping engine? or new table in OpenType font file? or new script/feature tag?

ctrlcctrlv commented 4 years ago
  1. A single font file should be able to shape any valid IDS. All IDS fonts don't need to do so, but the ideal IDS font should be able to; there should be nothing in the format stopping this.
  2. There are a few obvious changes to the font format which could make this simpler.

Ultimately what I need to do is make a prototype font and figure out where the low hanging fruit in the standard are. :)

mpsuzuki commented 4 years ago

(for item 1)

Thanks! Maybe, the ideal solution which people want to have a technology which can shape any IDS as far as its components are already coded. Fully I agree. But, sorry to say such, I think the way to go there is too long.

There were several CJK fonts which includes the components (saying more precisely, strokes), and many glyphs are described by the composition of them - like MingLiU in Windows XP era (I would attach some pictures in later). But, even in these fonts, many fine-tuned strokes are included in single font. So, composing a glyph from IDS purely, without any additional tweaking info, would be too intelligent task.

If we can agree "this font can render some known IDSs" is better than nothing as the first step, we can find a low hanging fruit :-).

ctrlcctrlv commented 4 years ago

But, even in these fonts, many fine-tuned strokes are included in single font. So, composing a glyph from IDS purely, without any additional tweaking info, would be too intelligent task.

An IDS font doesn't need to necessarily create a perfect glyph, exactly equal to how a human would draw it. I would argue that an ugly ideograph is better than no ideograph. It's likely my prototype will produce mostly ugly ideographs.

In terms of an IDS font that can only shape sequences the author thought of, this is already possible. The name of the font is HanaMinI. Here is its repetoire: https://raw.githubusercontent.com/cjkvi/HanaMinAFDKO/master/HanaMinI.features

mpsuzuki commented 4 years ago

Yes, yes, I know that. But, the implementation like HanaMinI is not easy to obtain the list of the supported IDSs (so, the library like fontconfig would be unable to search a font supporting specified IDS). Thus, still there would be a room to be improved.

If the arbitrary shaping is the essential feature, I'm afraid, the outline description language would be required to be extended. How do you think about the embedding of such font (for arbitrary shaping of IDS) into PDF, XPS or OOXML?

ctrlcctrlv commented 4 years ago

It's not difficult to get a list of GSUB substitutions, and fontconfig could do that. That'd be an issue in fontconfig though...not sure what in the standard would change.

My paper was about arbitrary shaping yes, shaping based on a list of known sequences is kind of out-of-scope I'm afraid.

mpsuzuki commented 4 years ago

OK, it's not good idea to continue the off-topic discussion, I should separate the issue for the font only for the designed set of IDSs.

Then, how about the extension of the outline description language? If font embedding is expected, the bytecode synthesis by the shaping engine should be cared.

tiroj commented 4 years ago

During the meeting yesterday, a point was raise about the need to accommodate IDS in run segmentation. So that should be flagged for discussion relative to this issue, especially if a GSUB or other OTL approach to IDS resolution is to be considered.