From iorsh at users.sourceforge.net  Tue Aug  5 16:05:53 2014
From: iorsh at users.sourceforge.net (Maxim Iorsh)
Date: Wed, 6 Aug 2014 00:05:53 +0300
Subject: Combining classes of Hebrew accents
Message-ID: <CADQ_TR7Tsv2EvZtzFS9mKWhtavxpejDVRy=icXjKg0U_aODt3w@mail.gmail.com>

Hello,

I propose to change combining classes for certain Hebrew accents.

Presently, the Hebrew accents belong to one of the following classes: 220
(below), 222 (below right), 228 (above left), 230 (above). Accordingly, the
canonical ordering puts "below" accents before "below right" accents, for
example.

Unfortunately, the resulting order is wrong. As Hebrew is a right-to-left
script, the accents which are located below the letter on the right should
go *before* accents which reside below the letter in the middle. The same
goes for accents above letters.

My proposal is to modify the combining class property as follows:

059A HEBREW ACCENT YETIV: ccc=219 "Below_Right_RTL"
05AD HEBREW ACCENT DEHI: ccc=219 "Below_Right_RTL"
05AE HEBREW ACCENT ZINOR: ccc=231 "Above_Left_RTL"

Alternatively, existing class 218 "Below_Left" could be assigned to 059A,
05AD and possibly renamed to "Below_Char_Start" or something similar, so
that it means "left" for LTR scripts and "right" for RTL scripts. The class
232 "Above_Right" could be assigned to 05AE and renamed accordingly.

Thank you,
 -- Maxim.

P. S. In a related note, does anybody know why Hebrew marks (05B0-05C7) are
assigned fixed combining classes? It looks like most of them would be
perfectly ok with 220 "Below" class, or other appropriate non-fixed classes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140806/d5c5b3d9/attachment.html>

From iorsh at users.sourceforge.net  Tue Aug  5 16:48:33 2014
From: iorsh at users.sourceforge.net (Maxim Iorsh)
Date: Wed, 6 Aug 2014 00:48:33 +0300
Subject: Combining classes of Hebrew accents
In-Reply-To: <CADQ_TR7Tsv2EvZtzFS9mKWhtavxpejDVRy=icXjKg0U_aODt3w@mail.gmail.com>
References: <CADQ_TR7Tsv2EvZtzFS9mKWhtavxpejDVRy=icXjKg0U_aODt3w@mail.gmail.com>
Message-ID: <CADQ_TR5GHdP+wbXdeLGbkq4oV7YtPbMOMQM+YujU4BMFJQAi-g@mail.gmail.com>

Almost forgot to mention,

05A0 HEBREW ACCENT TELISHA GEDOLA,
059D HEBREW ACCENT GERESH MUQDAM both should be 229 "Above_Right_RTL"

 -- Maxim.


On Wed, Aug 6, 2014 at 12:05 AM, Maxim Iorsh <iorsh at users.sourceforge.net>
wrote:

> Hello,
>
> I propose to change combining classes for certain Hebrew accents.
>
> Presently, the Hebrew accents belong to one of the following classes: 220
> (below), 222 (below right), 228 (above left), 230 (above). Accordingly, the
> canonical ordering puts "below" accents before "below right" accents, for
> example.
>
> Unfortunately, the resulting order is wrong. As Hebrew is a right-to-left
> script, the accents which are located below the letter on the right should
> go *before* accents which reside below the letter in the middle. The same
> goes for accents above letters.
>
> My proposal is to modify the combining class property as follows:
>
> 059A HEBREW ACCENT YETIV: ccc=219 "Below_Right_RTL"
> 05AD HEBREW ACCENT DEHI: ccc=219 "Below_Right_RTL"
> 05AE HEBREW ACCENT ZINOR: ccc=231 "Above_Left_RTL"
>
> Alternatively, existing class 218 "Below_Left" could be assigned to 059A,
> 05AD and possibly renamed to "Below_Char_Start" or something similar, so
> that it means "left" for LTR scripts and "right" for RTL scripts. The class
> 232 "Above_Right" could be assigned to 05AE and renamed accordingly.
>
> Thank you,
>  -- Maxim.
>
> P. S. In a related note, does anybody know why Hebrew marks (05B0-05C7)
> are assigned fixed combining classes? It looks like most of them would be
> perfectly ok with 220 "Below" class, or other appropriate non-fixed classes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140806/a2ef2d31/attachment.html>

From verdy_p at wanadoo.fr  Tue Aug  5 17:24:35 2014
From: verdy_p at wanadoo.fr (Philippe Verdy)
Date: Wed, 6 Aug 2014 00:24:35 +0200
Subject: Combining classes of Hebrew accents
In-Reply-To: <CADQ_TR7Tsv2EvZtzFS9mKWhtavxpejDVRy=icXjKg0U_aODt3w@mail.gmail.com>
References: <CADQ_TR7Tsv2EvZtzFS9mKWhtavxpejDVRy=icXjKg0U_aODt3w@mail.gmail.com>
Message-ID: <CAGa7JC0P16Xq8hq3E_09kosAtDXEejN7Vh2k-0As1=oymsOczw@mail.gmail.com>

This is a known issues that exists since years(and that has been discussed
heavily at that time). Unfortunately this CANNOT be changed and will never
be changed. Canonical combiing classes are immutable and assigned for ever
because they are part of character properties that MUST honor the
stability, and notably here, any change would break the stability of all
normalizations.

In cases where this could cause problems because two Hebrew combining marks
with a non-zero combining class have a significant order, the only solution
is to separate them with a combining grapheme joiner (CGJ) to preserver
their relative order. For modern Hebrew this is not a problem, you don't
need CGJ and nothing is needed: the existing canonical equivalence has no
impact on the interpretation even if the relative order of combining marks
proposed by the normalization is not the most logical. But this has no
impact.

All of these has been discussed. There will be no change. In fact the
situation is ven more complex than what you think when you look at Biblic
Hebrew where there a some words where the multiple diacritics can occur
over the same base letter and interact graphically in a complex way and
where the encoding order is highly significant.

In fact the problematic cases are effectively the dots occuring in the
middle (dagesh), the sin/shin dots. And the historic cantillation marks
(which ideally should have been assined a 0 combining mark, but you can
still emulate that behavior by prefixing a CGJ before these marks to make
sure they won't be reordered). There are also other specific issues for
Yiddish.

Some complex issue being in the encoding for the Biblic name of
Yerushalayim and the name of God and similar words with diphtongs
represented by multiple diacritics in a significant order (because there
are in fact some implied but unwritten base letters: the CGJ can be used
where the implied letter is missing to solve the issue).



2014-08-05 23:05 GMT+02:00 Maxim Iorsh <iorsh at users.sourceforge.net>:

> Hello,
>
> I propose to change combining classes for certain Hebrew accents.
>
> Presently, the Hebrew accents belong to one of the following classes: 220
> (below), 222 (below right), 228 (above left), 230 (above). Accordingly, the
> canonical ordering puts "below" accents before "below right" accents, for
> example.
>
> Unfortunately, the resulting order is wrong. As Hebrew is a right-to-left
> script, the accents which are located below the letter on the right should
> go *before* accents which reside below the letter in the middle. The same
> goes for accents above letters.
>
> My proposal is to modify the combining class property as follows:
>
> 059A HEBREW ACCENT YETIV: ccc=219 "Below_Right_RTL"
> 05AD HEBREW ACCENT DEHI: ccc=219 "Below_Right_RTL"
> 05AE HEBREW ACCENT ZINOR: ccc=231 "Above_Left_RTL"
>
> Alternatively, existing class 218 "Below_Left" could be assigned to 059A,
> 05AD and possibly renamed to "Below_Char_Start" or something similar, so
> that it means "left" for LTR scripts and "right" for RTL scripts. The class
> 232 "Above_Right" could be assigned to 05AE and renamed accordingly.
>
> Thank you,
>  -- Maxim.
>
> P. S. In a related note, does anybody know why Hebrew marks (05B0-05C7)
> are assigned fixed combining classes? It looks like most of them would be
> perfectly ok with 220 "Below" class, or other appropriate non-fixed classes.
>
> _______________________________________________
> Unicode mailing list
> Unicode at unicode.org
> http://unicode.org/mailman/listinfo/unicode
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140806/be676db7/attachment.html>

From wjgo_10009 at btinternet.com  Tue Aug 12 09:21:43 2014
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Tue, 12 Aug 2014 15:21:43 +0100
Subject: Off-topic: Tate Britain After Dark
Message-ID: <1407853303.53040.YahooMailNeo@web87802.mail.ir2.yahoo.com>



Off-topic: Tate Britain After Dark

On the following web page

http://www.unicode.org/policies/mail_policy.html

there is the following.

quote

A mail list is also a social organization, and as such, there will inevitably be some off-topic posting, fun, and games. This is not inherently discouraged unless it dominates a list for a length of time.

end quote

So hopefully the following is considered of interest to some of the people on this list.

http://afterdark.tate.org.uk

http://www.tate.org.uk/context-comment/blogs/how-do-you-build-robot

http://www.tate.org.uk/whats-on/tate-britain/special-event/after-dark

The Tate is a collection of several famous art galleries in the United Kingdom.

William Overington

12 August 2014


From sdaoden at yandex.com  Wed Aug 13 11:18:16 2014
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Wed, 13 Aug 2014 18:18:16 +0200
Subject: Off-topic: Tate Britain After Dark
In-Reply-To: <1407853303.53040.YahooMailNeo@web87802.mail.ir2.yahoo.com>
References: <1407853303.53040.YahooMailNeo@web87802.mail.ir2.yahoo.com>
Message-ID: <20140813171816.z6QN7O64%sdaoden@yandex.com>

William_J_G Overington <wjgo_10009 at btinternet.com> wrote:
 |http://afterdark.tate.org.uk

Let's just hope those won't cause any damages!
Heaven only knows who wrote their control software...

And how beautiful that old stuff looks when enlightened by
headlights!

--steffen

From fantasai.lists at inkedblade.net  Tue Aug 12 21:19:19 2014
From: fantasai.lists at inkedblade.net (fantasai)
Date: Tue, 12 Aug 2014 19:19:19 -0700
Subject: Request for Information
In-Reply-To: <20140724073742.6248cb29@JRWUBU2>
References: <53D010EC.9060204@inkedblade.net> <20140724073742.6248cb29@JRWUBU2>
Message-ID: <53EACB27.4070703@inkedblade.net>

On 07/23/2014 11:37 PM, Richard Wordingham wrote:
> On Wed, 23 Jul 2014 20:45:48 +0100
> fantasai <fantasai.lists at inkedblade.net> wrote:
>
>> I would like to request that Unicode include, for each writing system
>> it encodes, some information on how it might justify.
>
> Unicode encodes scripts, and I suspect CLDR only really supports living
> languages.  Scripts can be used for multiple writing systems - the
> example of the Latin script for Romaji in Japanese was given in the
> original post.
>
>>     a) Text justification typically expands at word-separating
>> characters, but may also expand between letters.
>>     b) Since this writing system does not use spaces, justification
>> typically expands between letters.
>
> Are you hoping for details on this?  This justification, which I've
> seen called 'Thai justification' in Microsoft Word, generally treats
> spacing combining marks (gc=Mc) like letters in the Tai Tham script when
> used for Tai Khuen.

Actually, for b) I was thinking more about Zh/Ja. I'm mostly hoping
for some kind of clues, however detailed (like the Tibetan chapter,
which devotes an entire page to justification) or superficial. Right
now I have nothing for minority scripts like Javanese. But in order
to display Javanese I have to make some kind of assumption, one way
or another.

>>     c) Javanese only breaks between clauses, where punctuation is used,
>>        resulting in horrendously ragged lines. (Did I get that right?)
>
> No.  The text samples I could find quickly show scripta continua, but I
> suspect the line breaks are occurring at word or syllable boundaries.
> If I am right about the constraint on line break position, then this
> can be recovered by marking the optional line breaks with ZWSP.  In
> addition, the consonants should be reclassified from AL to SA.

:) I picked this example because I was pretty sure that extrapolating
from the UAX14 data was going to give me a wrong answer. Thank you for
confirming.

Does the UTC think that including a statement or two about line
breaking conventions in the per-script descriptions is unnecessary
and inappropriate?

> However, such a change would be incompatible with a modern writing
> system in which words are separated by spaces (if such exists). I don't
> know what happens in Indonesian schools, so I can't report an error.
> Scripta continua and non-scripta continua in the same script are
> incompatible in plain text.

Not really. You can break at spaces and also break by dictionary,
and as long as the two methods agree on what is an unbreakable
"word", it will work. It's only if they disagree that you run
into a problem.

~fantasai

From petercon at microsoft.com  Thu Aug 14 17:52:34 2014
From: petercon at microsoft.com (Peter Constable)
Date: Thu, 14 Aug 2014 22:52:34 +0000
Subject: FYI: Ruble sign in Windows
Message-ID: <ee30070115fa41e59ac62498dfcd62d5@BN1PR0301MB0689.namprd03.prod.outlook.com>

For those interested, there is an update for Windows available now to add font, keyboard and locale data support for the Ruble sign that was added in Unicode 7.0. For details, see here:

http://support.microsoft.com/kb/2970228




Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140814/929d19f6/attachment.html>

From mark at macchiato.com  Thu Aug 14 20:31:01 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Thu, 14 Aug 2014 18:31:01 -0700
Subject: FYI: Ruble sign in Windows
In-Reply-To: <ee30070115fa41e59ac62498dfcd62d5@BN1PR0301MB0689.namprd03.prod.outlook.com>
References: <ee30070115fa41e59ac62498dfcd62d5@BN1PR0301MB0689.namprd03.prod.outlook.com>
Message-ID: <CAJ2xs_GH+G_TT9vv1US=orvNSv56K+6Sod+xwS=4QgwwsK7CRw@mail.gmail.com>

Cool, congratulations!


Mark <https://google.com/+MarkDavis>

 *? Il meglio ? l?inimico del bene ?*


On Thu, Aug 14, 2014 at 3:52 PM, Peter Constable <petercon at microsoft.com>
wrote:

>  For those interested, there is an update for Windows available now to
> add font, keyboard and locale data support for the Ruble sign that was
> added in Unicode 7.0. For details, see here:
>
>
>
> http://support.microsoft.com/kb/2970228
>
>
>
>
>
>
>
>
>
> Peter
>
> _______________________________________________
> Unicode mailing list
> Unicode at unicode.org
> http://unicode.org/mailman/listinfo/unicode
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140814/2be0d660/attachment.html>

From jkorpela at cs.tut.fi  Fri Aug 15 07:03:52 2014
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Fri, 15 Aug 2014 15:03:52 +0300
Subject: FYI: Ruble sign in Windows
In-Reply-To: <ee30070115fa41e59ac62498dfcd62d5@BN1PR0301MB0689.namprd03.prod.outlook.com>
References: <ee30070115fa41e59ac62498dfcd62d5@BN1PR0301MB0689.namprd03.prod.outlook.com>
Message-ID: <53EDF728.80700@cs.tut.fi>

2014-08-15 1:52, Peter Constable wrote:

> For those interested, there is an update for Windows available now to
> add font, keyboard and locale data support for the Ruble sign that was
> added in Unicode 7.0. For details, see here:
>
> http://support.microsoft.com/kb/2970228

The update seems to have been installed automatically into my deskop 
(Windows 7). Since I did not see any list of fonts in the details, I 
checked this myself. The fonts that support RUBLE SIGN (after the 
update) are: Arial, Calibri, Microsoft Sans Serif, Segoe UI, Tahoma, 
Times New Roman.

People who need to enter different currency symbols often might be 
interested in a keyboard layout that I designed and implemented for 
Windows: https://www.cs.tut.fi/~jkorpela/currency.html8

Yucca


From verdy_p at wanadoo.fr  Fri Aug 15 08:53:34 2014
From: verdy_p at wanadoo.fr (Philippe Verdy)
Date: Fri, 15 Aug 2014 15:53:34 +0200
Subject: FYI: Ruble sign in Windows
In-Reply-To: <53EDF728.80700@cs.tut.fi>
References: <ee30070115fa41e59ac62498dfcd62d5@BN1PR0301MB0689.namprd03.prod.outlook.com>
 <53EDF728.80700@cs.tut.fi>
Message-ID: <CAGa7JC2eM7A+_uk_NwBQ1rq2H9dqkRYV4aqOdbhnBb-FGtPobg@mail.gmail.com>

The list of updated fonts and keybaords is explicitly in the Microsoft KB
article, in the "File details" section (by OS type). That KB article is
even linked from the Windows Update summary.


2014-08-15 14:03 GMT+02:00 Jukka K. Korpela <jkorpela at cs.tut.fi>:

> 2014-08-15 1:52, Peter Constable wrote:
>
>  For those interested, there is an update for Windows available now to
>> add font, keyboard and locale data support for the Ruble sign that was
>> added in Unicode 7.0. For details, see here:
>>
>> http://support.microsoft.com/kb/2970228
>>
>
> The update seems to have been installed automatically into my deskop
> (Windows 7). Since I did not see any list of fonts in the details, I
> checked this myself. The fonts that support RUBLE SIGN (after the update)
> are: Arial, Calibri, Microsoft Sans Serif, Segoe UI, Tahoma, Times New
> Roman.
>
> People who need to enter different currency symbols often might be
> interested in a keyboard layout that I designed and implemented for
> Windows: https://www.cs.tut.fi/~jkorpela/currency.html8
>
> Yucca
>
>
> _______________________________________________
> Unicode mailing list
> Unicode at unicode.org
> http://unicode.org/mailman/listinfo/unicode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140815/26b6a0ab/attachment.html>

From wjgo_10009 at btinternet.com  Wed Aug 20 05:27:51 2014
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Wed, 20 Aug 2014 11:27:51 +0100
Subject: Abstract emoji as applied modern art
Message-ID: <1408530471.89997.YahooMailNeo@web87806.mail.ir2.yahoo.com>

Abstract emoji as applied modern art

Suppose that there are three abstract emoji defined.

These are designated as ae78901, ae78902 and ae78903.

Suppose that they can each be communicated within a plain text message by either a graphic or by a markup bubble constructed of a sequence of plain text characters.

Please find three graphic files attached to this post, showing the designs for the abstract emoji. These particular glyphs are each designed as a bit map design on a 7 by 7 grid. The graphic files are presented as 16 pixel by 16 pixel png files, made using the Microsoft Paint program, in the hope that that size will be of practical use.

Suppose that the markup bubble for the three abstract emoji is respectively as follows.

::78901:;

::78902:;

::78903:;

Each markup bubble is nine characters, namely two colons, five digits then a colon and a semicolon.

Suppose that the Localization Label in English for the three abstract emoji is respectively as follows.

The following person is staying at your hotel.

Please deliver the following message to that person.

The message is now complete.

Suppose that an example of use is as follows.

::78901:;
Margaret Gattenford
::78902:;
Dear Margaret
The framed print that you ordered has now arrived.
Yours sincerely
Albert
::78903:;

The message, in this example in English, could be in any language that can be represented using Unicode.

The hotel staff do not need to be able to understand the language used in the message in order to deliver it, all they need is to understand the meaning of the abstract emoji glyphs and be able to recognize the 789 sequences if the abstract emoji arrive in abstract text form.

In speech, when referring to a 789 sequence, please say, "seven-eight-nine sequence", localized into your own language.

The graphic files each show the glyph with a white border around them. If implementing the glyphs in an OpenType font please align the lower black edge of the glyph with the baseline of the font. The glyphs in the font would be unmapped and accessed by glyph substitution in the dlig table of the font using the nine-character markup bubble.

The markup bubble sequences have been designed so as to be, as far as is possible, language and script independent.

The designs are abstract yet sometimes influenced. For example, the designs for ae78902 and ae78903 are influenced by quotation marks.

This is intended as an open experiment.

Readers are welcome, if they so choose, to post a Localization Label for each of the three glyphs using whichever language they choose and to make fonts including the glyphs.

Readers are also welcome, if they so choose, to design and post more abstract emoji.

William Overington

20 August 2014
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ae78901.png
Type: image/png
Size: 133 bytes
Desc: not available
URL: <http://unicode.org/pipermail/unicode/attachments/20140820/e990e1ef/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ae78902.png
Type: image/png
Size: 136 bytes
Desc: not available
URL: <http://unicode.org/pipermail/unicode/attachments/20140820/e990e1ef/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ae78903.png
Type: image/png
Size: 136 bytes
Desc: not available
URL: <http://unicode.org/pipermail/unicode/attachments/20140820/e990e1ef/attachment-0002.png>

From shervinafshar at gmail.com  Wed Aug 20 15:41:57 2014
From: shervinafshar at gmail.com (Shervin Afshar)
Date: Wed, 20 Aug 2014 13:41:57 -0700
Subject: Abstract emoji as applied modern art
In-Reply-To: <1408530471.89997.YahooMailNeo@web87806.mail.ir2.yahoo.com>
References: <1408530471.89997.YahooMailNeo@web87806.mail.ir2.yahoo.com>
Message-ID: <CA+ONOD=Oju-_k1oqdB-80AUwL-NDGTkGV8reRvgrRSY-A5EPQg@mail.gmail.com>

I am a bit confused about the definitions of "modern art" and "emoji" here:

- Are QR, USAF 1951, ISO 12233, variety of fiducial markers (including
ISO-233-based OCR block U+2440-244A), and bar-codes also "applied modern
art"?
- Should Control Pictures (U+2400-243F) be considered emoji as well, simply
because they have a graphic representation?


? Shervin


On Wed, Aug 20, 2014 at 3:27 AM, William_J_G Overington <
wjgo_10009 at btinternet.com> wrote:

> Abstract emoji as applied modern art
>
> Suppose that there are three abstract emoji defined.
>
> These are designated as ae78901, ae78902 and ae78903.
>
> Suppose that they can each be communicated within a plain text message by
> either a graphic or by a markup bubble constructed of a sequence of plain
> text characters.
>
> Please find three graphic files attached to this post, showing the designs
> for the abstract emoji. These particular glyphs are each designed as a bit
> map design on a 7 by 7 grid. The graphic files are presented as 16 pixel by
> 16 pixel png files, made using the Microsoft Paint program, in the hope
> that that size will be of practical use.
>
> Suppose that the markup bubble for the three abstract emoji is
> respectively as follows.
>
> ::78901:;
>
> ::78902:;
>
> ::78903:;
>
> Each markup bubble is nine characters, namely two colons, five digits then
> a colon and a semicolon.
>
> Suppose that the Localization Label in English for the three abstract
> emoji is respectively as follows.
>
> The following person is staying at your hotel.
>
> Please deliver the following message to that person.
>
> The message is now complete.
>
> Suppose that an example of use is as follows.
>
> ::78901:;
> Margaret Gattenford
> ::78902:;
> Dear Margaret
> The framed print that you ordered has now arrived.
> Yours sincerely
> Albert
> ::78903:;
>
> The message, in this example in English, could be in any language that can
> be represented using Unicode.
>
> The hotel staff do not need to be able to understand the language used in
> the message in order to deliver it, all they need is to understand the
> meaning of the abstract emoji glyphs and be able to recognize the 789
> sequences if the abstract emoji arrive in abstract text form.
>
> In speech, when referring to a 789 sequence, please say, "seven-eight-nine
> sequence", localized into your own language.
>
> The graphic files each show the glyph with a white border around them. If
> implementing the glyphs in an OpenType font please align the lower black
> edge of the glyph with the baseline of the font. The glyphs in the font
> would be unmapped and accessed by glyph substitution in the dlig table of
> the font using the nine-character markup bubble.
>
> The markup bubble sequences have been designed so as to be, as far as is
> possible, language and script independent.
>
> The designs are abstract yet sometimes influenced. For example, the
> designs for ae78902 and ae78903 are influenced by quotation marks.
>
> This is intended as an open experiment.
>
> Readers are welcome, if they so choose, to post a Localization Label for
> each of the three glyphs using whichever language they choose and to make
> fonts including the glyphs.
>
> Readers are also welcome, if they so choose, to design and post more
> abstract emoji.
>
> William Overington
>
> 20 August 2014
> _______________________________________________
> Unicode mailing list
> Unicode at unicode.org
> http://unicode.org/mailman/listinfo/unicode
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140820/9c8f88a5/attachment.html>

From wjgo_10009 at btinternet.com  Thu Aug 21 08:19:02 2014
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Thu, 21 Aug 2014 14:19:02 +0100
Subject: Abstract emoji as applied modern art
In-Reply-To: <CA+ONOD=Oju-_k1oqdB-80AUwL-NDGTkGV8reRvgrRSY-A5EPQg@mail.gmail.com>
References: <1408530471.89997.YahooMailNeo@web87806.mail.ir2.yahoo.com>
 <CA+ONOD=Oju-_k1oqdB-80AUwL-NDGTkGV8reRvgrRSY-A5EPQg@mail.gmail.com>
Message-ID: <1408627142.93086.YahooMailNeo@web87802.mail.ir2.yahoo.com>


Shervin Afshar wrote as follows:

> I am a bit confused about the definitions of "modern art" and "emoji" here:

Thank you for replying to my post.

I think of emoji as picture characters used in a message, usually a message conveyed by electronic means. An emoji conveys a meaning through the language barrier, thus allowing communication through the language barrier.

Yet the pictures used for emoji are usually, thus far, representational pictures.

I am thinking that the picture used in an emoji could be an abstract picture.

If an abstract picture is used to define an emoji character then there needs to be some guidance, external to the particular message where such an abstract emoji is used, as to what meaning the picture is being used to convey.

Since the idea is that the abstract emoji should convey meaning through the language barrier, that guidance needs to be localized so that a person reading the message can understand its meaning, regardless of which one or more natural languages he or she has knowledge.

I have referred to the pictures that I have produced for these abstract emoji as modern art because they are not traditional representational pictures.

I have heard of people looking at an abstract picture in an art gallery and asking "What does it mean?".

If, say, ae78901 were produced as a picture for display in an art gallery then there is an answer to the question "What does it mean?".

Thus it is applied modern art, art that can be applied to a practical application, rather than just being art that is just there.

For the avoidance of doubt I am not in any way criticising art that is just there: I like art, including modern art.

William Overington

21 August 2014
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140821/7ab455f4/attachment.html>

From verdy_p at wanadoo.fr  Thu Aug 21 13:27:29 2014
From: verdy_p at wanadoo.fr (Philippe Verdy)
Date: Thu, 21 Aug 2014 20:27:29 +0200
Subject: Abstract emoji as applied modern art
In-Reply-To: <1408627142.93086.YahooMailNeo@web87802.mail.ir2.yahoo.com>
References: <1408530471.89997.YahooMailNeo@web87806.mail.ir2.yahoo.com>
 <CA+ONOD=Oju-_k1oqdB-80AUwL-NDGTkGV8reRvgrRSY-A5EPQg@mail.gmail.com>
 <1408627142.93086.YahooMailNeo@web87802.mail.ir2.yahoo.com>
Message-ID: <CAGa7JC1tDqzt43KJY2ykwcfNDuDD9ROP9ZXsFKad+kVEViA7pw@mail.gmail.com>

Out of scope of Unicode, Please stop inventing new things and posting them
heren that do not conform to the encoding rules: all encoded characters
need to demonstrate their acutal usage accessible to a sizeable community
(or expected to be used widely such as new currency symbols).

Emojis have been encoded because they are widely used (their graphical
aspect does not matter much, even their color, so you can expect
differences for example between their use in Google Hangouts, smartphones
under Android, Windows or iOS, instant messengers, email agents and
websites (the web is full of collections of emojis with various styles, and
users on some sites can also choose their preferred thematic collection for
the same emojis). Emojis have passed the test being abstract characters
because they convey the same meaning under these various styles. And most
importantly, they do not need special learning by users to understand them
in most cases, as they are explicit (in their context of use, which may
influence them, just like letters are contextually read and understood in
words or sentences).

What you propose is just personal "art" and artistis creations are out of
scope of Emojis, and your example glyphs have no usage except you, and are
unreadable except by you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140821/3ac8fb2f/attachment.html>

From wjgo_10009 at btinternet.com  Tue Aug 26 05:12:03 2014
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Tue, 26 Aug 2014 11:12:03 +0100
Subject: A colour font art publication project
Message-ID: <1409047923.63214.YahooMailNeo@web87802.mail.ir2.yahoo.com>

A colour font art publication project

Some readers might enjoy the following thread.

http://forum.high-logic.com/viewtopic.php?f=10&t=5152

The thread contains a transcript of some notes that I produced earlier this morning as I carried out a project involving a colour font using a number of software packages.

There are two PDF attachments after the transcript.

William Overington

26 August 2014