Re: Tag characters and in-line graphics (from Tag characters)

Perhaps the solution to at least some of the various issues that have been discussed in this thread is to define a tag letter z as a code within the local glyph memory requests, as follows.

----
Local glyph memory, for use in compressing a document where the same glyph is used two or more times in the document:
3t7r means this is local glyph 3 being defined at its first use in the document as 7 red pixels
3h here local glyph 3 is being used
3z7r means this is local glyph 3 being defined, though not used, at the start of the document as 7 red pixels
More than one local glyph could be defined at the start of the document, as desired.
----
This would mean that use of such a glyph within the document would be by just using the quite short base character followed by tag characters sequence using the h request. This would enable document editing to be easier to accomplish.
----
A mechanism to be able to use the method to define a glyph linked to a Unicode code point would be a useful facility to add for use in a situation where the glyph is for a regular Unicode character.
----
May I mention something that I forgot to mention earlier please?
When only one pixel of a particular colour is being specified, it can be specified using just the code for the colour.
For example, for 1 red pixel please use r on its own, there is no need to use 1r though 1r should be made to work just in case anyone does use that format.
There was a time when I used to use the FORTH programming language and this format of first inputting the number then the operator is based on the way that the FORTH programming language works.
William Overington
2 June 2015
----Original message----
From : wjgo_10009_at_btinternet.com
Date : 27/05/2015 - 17:26 (GMTST)
To : unicode_at_unicode.org
Subject : Tag characters and in-line graphics (from Tag characters)
Tag characters and in-line graphics (from Tag characters)
This document suggests a way to use the method of a base character together with tag characters to produce a graphic. The approach is theoretical and has not, at this time, been tried in practice.
The application in mind is to enable the graphic for an emoji character to be included within a plain text stream, though there will hopefully be other applications.
The base character could be either an existing character, such as U+1F5BC FRAME WITH PICTURE, or a new character as decided. Tests could be carried out using a Private Use Area character as the base character.
The explanation here is intended to explain the suggested technique by examples, as a basis for discussion. In each example, please consider for each example that the characters listed are each the tag version of the character used here and that they all as a group follow one base character.
The examples are deliberately short so as to explain the idea. A real use example might have around two hundred or so tag characters following the base character, maybe more, sometimes fewer.
Examples of displays:
Each example is left to right along the line then lines down the page from upper to lower.
7r means 7 pixels red
7r5y means 7 pixels red then 5 pixels yellow
7r5y-3b means 7 pixels red then 5 pixels yellow then next line then 3 pixels blue
Examples of colours available:
k black
n brown
r red
o orange
y yellow
g green (0, 255, 0)
b blue
m magenta
e grey
w white
c cyan
p pink
d dark grey
i light grey (thus avoiding using lowercase l so as to avoid confusion with figure 1)
f deeper green (foliage colour) (0, 128, 0)
Next line request:
- moves to the next line
Local palette requests:
192R224G64B2s means store as local palette colour 2 the colour (R=192, G=224, B=64)
7,2u means 7 pixels using local palette colour 2
Local glyph memory, for use in compressing a document where the same glyph is used two or more times in the document:
3t7r means this is local glyph 3 being defined at its first use in the document as 7 red pixels
3h here local glyph 3 is being used
The above is for bitmaps. It would be possible to use a similar technique to specify a vector glyph as used in fontmaking using on-curve and off-curve points specified as X, Y coordinates together with N for on-curve and F for off-curve. There would need to be a few other commands so as to specify places in the tag character stream where definition of a contour starts and so as to separate the definitions of the glyphs for a colour font and so on. This could be made OpenType compatible so that a received glyph could be added into a font.
Please feel free to suggest improvements. One improvement could be as to how to build a Unicode code point into a picture so that a font could be transmitted.
William Overington
27 May 2015