On Tuesday, November 5, 2019, 08:06:08 PM GMT-5, Asmus Freytag <asmusf@ix.netcom.com> wrote:
Bill,
in continuation of our discussion,
here's how I would have replied if you had asked this in the
session:
First, you write: "The ideal solution,
of course, would be for the Unicode folks to create new
pre-composed code points for these problem cases. But I suspect
there is little chance of them doing so before our report is due.
So, we will have to figure out an alternate approach to
recommend."
Unicode has an explicit policy of not
adding any more precomposed code points for the kinds of
combinations considered. So there's a definite answer that such
will not happen. Ever.
>> Good to know what Unicode's policy is on this. I wonder why, given that they have a bunch of pre-composed code points which are not used in any of what we fondly believe are the major languages using the Latin alphabet. Presumably they had their reasons for choosing the ones that they did.
>> If those reasons include indications that we missed a major language or three that we should have included, that would be useful to know ASAP.
I would say that Courier New is perhaps
an unfortunate choice of reference font. Some other people may
have more details, or actual knowledge of what MSFT's plan is for
that font, but it is my impression that the Courier New font was
state of the art in the past, and it certainly looks like has not
been maintained actively to cover more languages (and frankly, I
can't recall seeing it much recently).
>> We'll need to discuss whether to shift to a different mono-width font for out analysis. On one hand, there would be a lot of work to consider redoing -- which would take time that we probably don't have. On the other hand, there's something to be said for using the same set of fonts throughout the analysis. Perhaps we can decide that one exception, for the non-pre-composed cases, is the least bad solution. As I say, we'll have to thrash it out.
There are other more recent monowidth fonts such as Lucida Console. See screen shot at the end. I've also appended the results for Segoe UI which is the font used in my browser (Firefox on Windows7).
>> Clearly we have been handicapped by none of us being expert in which fonts are growing obsolete and which are more current. As you say, the universe of Latin fonts is enormous. Clearly we couldn't look at anything like the whole. For example, we totally ignored all the cursive-based fonts -- which would have, among other things, generated a bunch more variants. But we are where we are at the moment.
There's a near infinite universe of
Latin-script fonts, and many do not attempt to cover the entire
script. If we include hyperlinks in text (those showing the URL)
there is no way we can predict which fonts a user will see a
domain name in.
We have three choices here:
(1) remove from the Latin LGR all code
points/sequences not rendered reliably in any font
(2) remove from the Latin LGR all code
points/sequences not rendered reliably in any "well-known" font
(3) remove from the Latin LGR all code
points/sequences not rendered reliably in common user interface
fonts: Windows, iOS, Android and all browsers if they don't use
platform fonts (latest version)
Because of the way Latin-script fonts
tend to subset, there's no way that (1) is a reasonable choice in
my view.
>> Absolutely agree. Or even possible.
The problem with (2) is that some
"well-known" fonts are tied to early versions of a given platform
and they *may* not be maintained any longer - while some of them
are still widely used, they have been replaced for UI purposes by
more modern / more capable fonts. Effectively, they may be
retained as legacy - so that you can still view and edit documents
that were created in them. Less well-known fonts (such as Arial
Unicode MS) may not have made the cut and aren't routinely
available any more. So the fact that a font is well-known
increases the likelihood that it is a legacy font. Taken together,
these considerations would argue against (2).
>> As noted, we would need outside advice on which fonts are both "well-known" and modern (i.e. not legacy) in order to attempt 2.
That leaves (3) as a "reasonable"
choice for making a cut. I know you'd appreciate that choice of
term :). It is also effectively forward-looking, because more
support tends to be added to newer fonts/systems and that process
looks like it would only continue.
By all indication, more modern text
fonts like Calibri, and modern UI fonts like Segoe UI do not have
issues with these code points, and I simply can't imagine Google's
Noto fonts would either.
>> I'm not quite clear what you are recommending that we do here. Are you suggesting that we go back and redo using these three fonts? Or something else?
Looking at the screen shot in context
with the reasoning above, it seems to me that we are good, but if
the Latin GP wants to document the issue (that many Latin fonts do
subset the range of code points/glyphs/combinations that they
support), that would be OK (if it doesn't otherwise delay the
project).
>> OK, notwithstanding the above, I'm reading this as saying that
1) we can stick with the fonts we are using, and
2) we can continue including the combination glyphs that I was concerned about, regardless of their issues in Courier New
>> If that is not a correct understanding, please let me know.
A./
PS: I have blind copied the other IP
members
Screenshot:
Instead of Arial, the screenshot shows
Calibri in the left column, despite the header.
>> In Word (Windows 10), I get ɛ̱̈e rendered as problematic even in Lucida Console -- although it renders fine in Firefox for email. Just FYI. Inconsistency among word processing softwares is a real pain, but one we will probably never get away from.
On 11/5/2019 10:32 AM, Sarmad Hussain
wrote:
FYI; please see below.
Regards,
Sarmad
From: Bill Jouris <bill.jouris@insidethestack.com>
Reply-To: Bill Jouris <bill.jouris@insidethestack.com>
Date: Monday, November 4, 2019 at 6:03 PM
To: Sarmad Hussain <sarmad.hussain@icann.org>
Subject: [Ext] Stacking
Hi Sarmad,
In speaking with Asmus after the meeting today, he indicated an interest in seeing what we are looking at with stacking. Perhaps you could share the attached with him, or even the whole IP -- with the caveat that this is me reporting on what I found, and the GP has not yet decided what should be done in these cases.
Perhaps the IP will have some ideas on how to deal with these cases.
Thanks
Bill Jouris
Inside Products
bill.jouris@insidethestack.com
831-659-8360
925-855-9512 (direct)
_______________________________________________ Fab5 mailing list Fab5@icann.org https://mm.icann.org/mailman/listinfo/fab5 _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.