On Fri, 5 May 2017 18:46:17 +
Michael Bear via Unicode wrote:
> But
> if the cry for space gets REALLY desperate, I’ll merge identical
> glyphs into one glyph. Obviously, I won’t do this for more
> problematic merges, only glyphs in similar scripts with similar
>
Philippe Verdy wrote,
> Code2000 ... uses the same font-wide strategy for hinting also
> creates lots of caveats: ...
Code2000 does not have hinting instructions; that's the font-wide strategy.
> Finally the bad thing about Code2000 is about font metrics, notably
> baselines: while you want to
> On 1 May 2017, at 21:12, Michael Bear via Unicode wrote:
>
> I am trying to make a music notation font. It will use the Musical Symbols
> block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not
> being very complete, I added some extra characters...
Additionally, I will only do OT features that are absolutely necessary for a
certain script, not unnecessary (although stylish!) features, e.g. I will
include things like mark positioning and init/medi/fina forms for Arabic, while
leaving out small caps, swashes, and extensive ligatures. (In an
On Thu, 4 May 2017 23:13:08 +
Michael Bear via Unicode wrote:
> I plan to do everything in the plane EXCEPT for the surrogates, which
> you’re not supposed to encode in fonts anyway, which leaves room for
> about 2,048 more glyphs for OpenType features.
There are, if I
“How much margin do you have for the BMP? There are a fair few
variation sequences, on top of all the contextual forms and conjuncts.”
I plan to do everything in the plane EXCEPT for the surrogates, which you’re
not supposed to encode in fonts anyway, which leaves room for about 2,048 more
You cannot cover a full plane with a single font. There are other factors
such as total size the also limit severely their use. We have to live with
the limitations of OpenType. In addition a giant font is hard to maintain,
version and update without breaking usages.
Font auhtors should focus
On Thu, 4 May 2017 05:01:17 +0200
Philippe Verdy via Unicode wrote:
> Rendering Devanagari with OpenType does not require any PUA
> assignment in that font for variants. The sequences are mapped
> directly using subtables and the rules defined in OpenType for that
> script.
2017-05-03 9:49 GMT+02:00 Richard Wordingham via Unicode <
unicode@unicode.org>:
> On Tue, 2 May 2017 05:08:27 +0200
> Philippe Verdy via Unicode wrote:
>
> > Consider also that the BMP is almost full, the remaining few holes
> > are kept for isolated characters that may be
Ken Whistler wrote:
> I suggest the following:
> 10BEDE for an English flag (reminding one of Bede the Venerable)
> 10CADF for a Welsh flag (harking to Cadfan ap Iago, King of Gwynedd)
> 10A1BA for a Scottish flag (for Alba, of course)
> Surely those would work for you!
Thank you for your
On 5/3/2017 3:20 AM, William_J_G Overington via Unicode wrote:
Surely a single code point could be found. Single code points are being found
for various emoji items on a continuing basis. Why pull up the ladder on
encoding some flags each with a single code point?
Yes, a single code point
I think the UTC just wants to avoid the controversy and blame of deciding which flags are worthy of inclusion.However, I think that emoji users who are aware of Unicode will blame Unicode for whatever the vendors pickDavid Faulks
Richard Wordingham wrote:
U+1F3F4 U+E0067 U+E0062 U+E0065 U+E006E U+E0067 U+E007F (English flag)
I looked at that and I realized that although I had effectively seen that
encoding in http://www.unicode.org/reports/tr51/tr51-11.html though expressed
differently, it was only when I saw
On Tue, 2 May 2017 05:08:27 +0200
Philippe Verdy via Unicode wrote:
> Consider also that the BMP is almost full, the remaining few holes
> are kept for isolated characters that may be added to existing
> scripts, or permanently reserved to avoid clashes with legacy
>
Consider also that the BMP is almost full, the remaining few holes are kept
for isolated characters that may be added to existing scripts, or
permanently reserved to avoid clashes with legacy softwares using simple
code remappings between distinct blocks, or to perform simple case
conversions
On Mon, 1 May 2017 23:03:53 +
Michael Bear via Unicode wrote:
> “Rather than using "unused code positions", I would always recommend
> to use some of the Private Use code points.” Consider it done.
>
> “What is the intended usage of your font? Music
> On May 1, 2017, at 3:12 PM, Michael Bear via Unicode
> wrote:
>
> I am trying to make a music notation font. It will use the Musical Symbols
> block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not
> being very complete, I added some extra
“Rather than using "unused code positions", I would always recommend to use
some of the Private Use code points.”
Consider it done.
“What is the intended usage of your font? Music score
applications? others?”
I am simply going to make a series of full Unicode fonts (which, due
Bad news, I’m afraid.
What is the intended usage of your font? Music score applications? others? The
overall problem with musical notation is, there is no comprehensive character
encoding standard and no generally working text and layout composing method
established. In the light of that fact
On 5/1/2017 12:12 PM, Michael Bear via
Unicode wrote:
I am trying to make a music notation font.
It will use the Musical Symbols block in Unicode
(1D100-1D1FF), but, since that block has a bad rep for not
20 matches
Mail list logo