Re: UTF-8 variant selector + Mac OS X: characters

7 views
Skip to first unread message

Michael Bäuerle

unread,
Jul 15, 2015, 8:26:08 AM7/15/15
to fltkg...@googlegroups.com
MacArthur, Ian (Selex ES, UK) wrote:
> Michael Bäuerle wrote:
> >
> > @Ian:
> > In September you have written that you know a way how to fix this.
> > Would the fix in your mind also catch this issue or would variation
> > selectors be a problem in general on X11 too?
>
> The specific issue with my X11 hack, as noted above, is that the
> code currently measures "the wrong string"; the "fix" for my hack,
> that I alluded to back in September, was to always pass strings
> through my substitution process, both when rendering and measuring
> them (though this might often entail effectively running
> substitution on each string twice in some cases.) [...]

Thank you for explaining things in detail.

> I have not done this because it will surely have a performance
> impact, will involve refactoring a fair bit of code, and I just
> never got around to it.

I still hope to see this working sometime in the future.

Maybe there is a chance to get the performance impact only if glyph
substitution really is enabled (currently this is be done with a
function call, so the program may decide whether it want "fast" or
"look nice").

> [...]
> As regards variant glyph selector substitution, I am not sure to
> what extent X11/XFT really understands that, or if we need to do
> something in fltk to make it work.
>
> I suspect it does not really work at all at present (as you report
> below...)

Looks like it is currently handled wrong as a separate glyph. Or not
"handled" at all from a different point of view.

The workaround I thought about is stripping all variation selectors
(or at least replacing them with something like a "zero width space"
for rendering). But maybe this is not as simple as I expect ...

MacArthur, Ian (Selex ES, UK)

unread,
Jul 15, 2015, 8:55:39 AM7/15/15
to fltkg...@googlegroups.com
> > Michael Bäuerle wrote:
> > >
> > > @Ian:
> > > In September you have written that you know a way how to fix this.
> > > Would the fix in your mind also catch this issue or would variation
> > > selectors be a problem in general on X11 too?
> >
> > The specific issue with my X11 hack, as noted above, is that the
> > code currently measures "the wrong string"; the "fix" for my hack,
> > that I alluded to back in September, was to always pass strings
> > through my substitution process, both when rendering and measuring
> > them (though this might often entail effectively running
> > substitution on each string twice in some cases.) [...]
>
> Thank you for explaining things in detail.

Assuming I know what I am talking about; not a safe thing to assume I suggest.


> > I have not done this because it will surely have a performance
> > impact, will involve refactoring a fair bit of code, and I just
> > never got around to it.
>
> I still hope to see this working sometime in the future.

Yes, me too; the constraint has been time to get round to it, and a fear of how much I'd need to change to get it working... And a lingering suspicion (in the absence of any metrics) that dropping per-glyph measurement and switching to whole-string measurement might actually end up faster for us nowadays (but be a much more scarily invasive change in the fltk core...)


> Maybe there is a chance to get the performance impact only if glyph
> substitution really is enabled (currently this is be done with a
> function call, so the program may decide whether it want "fast" or
> "look nice").

Yes that was my intent. I want the "fast" scheme to fall back to basically use the legacy code (albeit very slightly altered to fit) and the "complex" scheme should use the substitution path on any string that contains a word that can not be rendered in the current font.


>
> > [...]
> > As regards variant glyph selector substitution, I am not sure to
> > what extent X11/XFT really understands that, or if we need to do
> > something in fltk to make it work.
> >
> > I suspect it does not really work at all at present (as you report
> > below...)
>
> Looks like it is currently handled wrong as a separate glyph. Or not
> "handled" at all from a different point of view.
>
> The workaround I thought about is stripping all variation selectors
> (or at least replacing them with something like a "zero width space"
> for rendering). But maybe this is not as simple as I expect ...


That's what I'd envisaged too; assuming we can not easily "fix" this to be correct, then either we "sanitize" the strings to strip out the variant selectors altogether (since it appears that our X11 and Win32 ports don't seem to handle them at all, and our OSX port gets it wrong), or we somehow fix our string rendering so that it treats the variant selectors as non-spacing, non-printing glyphs so that we do not erroneously display any "bad" glyphs.

To me, "sanitizing" the string sounds like it might be easier, but...




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Reply all
Reply to author
Forward
0 new messages