Peter Constable wrote:
> William, you completely miss the point: As long as Unicode is the way to
> provide emoji to consumers, their needs and desires will not be best or fully
> met. Unicode as an AND gate is too many AND gates.
Ah, I understand what you mean now.
In my feedback of 7 March 2017 to PRI #348 on the Length of Tag Sequences I
included the following.
quote
.... for example, a vector glyph in a platform-independent colour-font-style
contour format could be expressed using tag characters.
end quote
Following your post and my now understanding your meaning I have written some
notes about the above possibility.
Previously I have made some colour fonts using the High-Logic FontCreator
program.
I do not claim to be expert on the OpenType colour font format, yet I know
about the idea of having several glyphs with each such glyph being of one
colour and then combining them to produce a colourful glyph and I also know
about the option to include a default monochrome glyph.
I enjoy trying to devise encoding systems, so I have tried to produce a way to
send the information for a colourful glyph within a tag sequence.
I am thinking that a future email or text message reception system could decode
the tag sequence and add a colourful glyph to the font being used to display
the message.
This method, if people can get it to work satisfactorily, would allow custom
vector glyph emoji within an interoperable plain text system.
Here is a transcript of what I have produced so far. Readers of this thread are
invited to have a look at the idea and are welcome to try to implement it if
they so choose. If any additions are needed, or indeed if any changes are
needed, please say. There needs to be a way so that the tag sequence for the
glyph for a particular character is only sent once in a message even though the
character may be used more than once in the message.
Tags and custom vector glyph emoji
Some notes as at Monday 3 April 2017 19:04 pm British Summer Time
A tag sequence for this purpose starts with a capital letter V standing for
vector format.
At the start of the sequence a:=255; b:=0; g:=0; m:=1; p:=0; r:=0; x:=0; y:=0;
w:=1000;
At the start of the sequence the points buffer is empty, the contours buffer is
empty and the glyphs buffer is empty.
The system uses a special-purpose virtual computing engine within a software
sandbox. The special-purpose virtual computing engine has no commands for loops
and is a single pass interpretative system.
----
Letters that are each used both as a command and also as the name of a register
in the special-purpose virtual computing engine.
a means {a:=p; p:=0; m:=0;}
b means {b:=p; p:=0; m:=0;}
g means {g:=p; p:=0; m:=0;}
m means {m:=1;}
p means {p:=0;}
r means {r:=p; p:=0; m:=0;}
x means {x:=p; p:=0;}
y means {y:=p; p:=0;}
w means {w:=p; p:=0;}
----
Letters that are used as a command but not as the name of a register in the
special-purpose virtual computing engine.
c means {define a closed contour from the points in the points buffer; clear
the points buffer ready for the next point; x:=0; y:=0; p:=0;}
d means {define a glyph from the contour or contours in the contours buffer, if
m=1 then the the glyph is the first glyph and is the monochrome glyph, else the
glyph is of colour (r, g, b, a) and is not the first glyph; clear the contours
buffer ready for the next glyph;clear the points buffer ready for the next
point; a:=255; b:=0; g:=0; r:=0; x:=0; y:=0; p:=0; m:=0;}
The use of the m register is so that a default monochrome glyph may optionally
be included as the first glyph defined. If any component of the colour or
opacity is defined before a d command is used, then the monochrome component is
left empty.
f means {define an off curve point using x and y; x:=0; y:=0; p:=0;}
h means {define a complete glyph of advance width w from the glyph or glyphs in
the glyphs buffer and have it ready for access by the main program; halt;}
n means {define an on curve point using x and y; x:=0; y:=0; p:=0;}
----
Digits
Digits 0 .. 9 each mean p:=10*p + (digit);
The system is designed to be notionally for an emoji glyph within a virtual
space of (x from 0 .. 1000 and y from 0 .. 1000). These values may be scaled to
fit with the metrics of a real world font with which a glyph communicated using
this system is applied.
----
A tag sequence for this purpose ends with a cancel tag.
----
Some basic examples of parts of a tag sequence to provide an idea of how the
system would be used.
The following part of a tag sequence would set the x register to have the value
250.
250x
The following part of a tag sequence would define an on-curve point at (x,y) =
(250, 900)
250x900yn
The following part of a tag sequence would define a contour.
250x900yn800x500yf250x100ync
The following part of a tag sequence would define a colour glyph that has one
contour.
250x900yn800x500yf250x100ync255b128gd
----
Conclusion
It seems that it would be possible for such a system to work, though the tag
sequences would be quite long, yet the system could allow a colourful glyph to
be expressed in an interoperable plain text format without needing any file
attachment to the plain text sequence.
William Overington
Monday 3 April 2017
