In my post of 22 May 2015, reproduced below, is the following.
... and then the plain text encoding of a particular localizable sentence
would be defined as being expressed as the LOCALIZABLE SENTENCE BASE
CHARACTER character followed by the code for the localizable sentence
specified in the
Mark E. Shoulson mark at kli dot org wrote:
Isn't this what webfonts are all about? You specify a font in the
stylesheet, give it a URL, and your browser goes and downloads it and
displays the text in it.
That's great if you have a stylesheet, a URL, and a browser. HTML is
fancy text, and
2015-06-07 18:39 GMT+02:00 Doug Ewell d...@ewellic.org:
Mark E. Shoulson mark at kli dot org wrote:
Isn't this what webfonts are all about? You specify a font in the
stylesheet, give it a URL, and your browser goes and downloads it and
displays the text in it.
That's great if you have a
On 6/4/2015 17:03 , Chris wrote:
This whole discussion is about the fact that it would be technically
possible to have private character sets and private agreements that
your OS downloads without the user being aware of it.
The sticky issues are not the questions of how to make available
On 2015/06/04 17:03, Chris wrote:
I wish Steve Jobs was here to give this lecture.
Well, if Steve Jobs were still around, he could think about whether (and
how many) users really want their private characters, and whether it was
worth the time to have his engineers working on the solution.
Asmus Freytag wrote about security issues.
This is interesting reading and I have learned a lot from the post about
various security issues.
Whilst the post is in this thread and follows from a post in this thread, the
topic has seemed to moved to the Custom characters thread.
I note that what
I wrote, crumpled up, and threw away about three different responses. I
thought about ISO 2022 and about accessing the web for every PUA
character, as Asmus mentioned, and about the size of the user base, as
Martin mentioned. I thought about character properties and about
ephemerality.
I didn't
No, that's why you include a reference to the font in the private agreement,
so that interested parties can install it and see the special character(s).
People with their iphones and ipads and so forth don’t want to have “private
agreements”, they don’t want to “install character sets”. The
On 4 Jun 2015, at 10:59 am, David Starner prosfil...@gmail.com wrote:
On Wed, Jun 3, 2015 at 5:46 PM Chris idou...@gmail.com
mailto:idou...@gmail.com wrote:
I personally think emoji should have one, single definitive representation
for this exact reason.
Then you want an image. I
On 3 Jun 2015, at 11:24 pm, David Starner prosfil...@gmail.com wrote:
Chris wrote:
There is no way to compare 2 HTML elements and know they are talking about
the same character
That's because character identity is a hard problem. Is the emoji TIGER the
same as TONY THE TIGER or as
So what you’re saying is that the current situation where you see an empty
square □ for unknown characters is better than seeing something useful?
—
Chris
On Thu, Jun 4, 2015 at 12:59 AM, Doug Ewell d...@ewellic.org wrote:
Chris idou747 at gmail dot com wrote:
Right now, what happens if you
On Wed, Jun 3, 2015 at 5:46 PM Chris idou...@gmail.com wrote:
I personally think emoji should have one, single definitive representation
for this exact reason.
Then you want an image. I don't see what's hard about that.
The community interested in tony the tiger can make decisions like
Compression is even more important today on mobile networks: mobile apps
are very verbose over the net, and you can easily pay the extra volume. In
addition, mobile networks are frequently much slower than what they are
advertized, even if you pay the extra subscription to get 3G/4G, you depend
on
Earlier in this thread, on 2 June 2015, I wrote as follows:
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.
I have now thought of a mechanism
Chris wrote:
There is no way to compare 2 HTML elements and know they are talking
about the same character
That's because character identity is a hard problem. Is the emoji TIGER the
same as TONY THE TIGER or as TONY THE TIGER GIVING THE VICTORY SIGN?
Chris idou747 at gmail dot com wrote:
Right now, what happens if you have a domain or locale requirement for
a special character?
That's what the PUA is for. Assign a PUA code point to your special
character, create a font which implements the PUA character, create a
brief private agreement
2015-06-04 2:59 GMT+02:00 David Starner prosfil...@gmail.com:
You can’t iterate over compressed bits. You can’t process them.
Why not? In any language I know of that has iterators, there would be no
problem writing one that iterates over compressed input. If you need to
mutate them, that is
Chris John idou747 at gmail dot com wrote:
So what you’re saying is that the current situation where you see an
empty square □ for unknown characters is better than seeing something
useful?
No, that's why you include a reference to the font in the private
agreement, so that interested
Once again no ! Unicode is a standard for encoding characters, not for
encoding some syntaxic element of a glyph definition !
Your project is out of scope. You still want to reinvent the wheel.
For creating syntax, define it within a language (which does not need new
characters (you're not
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
On 2015/06/03 07:55, Chris wrote:
As you point out, The UCS will not encode characters without a demonstrated
usage.”. But there are use cases for characters that don’t meet UCS’s criteria for a
world wide standard, but are necessary for more specific use cases, like specialised
regional,
I was asking why the glyphs for right arrow ➡ are inconsistent in many sources,
through a couple of iterations of unicode. Perhaps I might observe that one of
the reasons is there is no technical link between the code and the glyph. I
can’t realistically write a display engine that goes to
Martin, you seem to be labouring under the impression that HTML5 is a
substitute for character encoding. If it is, why do we need unicode? We could
just have documents laden with IMG tags, and restrict ourselves to ascii.
It seems I need to spell out one more time why HTML is not character
On 3 Jun 2015, at 11:22 am, Martin J. Dürst due...@it.aoyama.ac.jp wrote:
On 2015/05/29 11:37, John wrote:
If I had a large document that reused a particular character thousands of
times,
Then it would be either a very boring document (containing almost only that
same character) or
On 2015/05/29 11:37, John wrote:
If I had a large document that reused a particular character thousands of times,
Then it would be either a very boring document (containing almost only
that same character) or it would be a very large document.
would this HTML markup require embedding that
No, nothing about what you propose, which is to encode graphics directly
with a custom syntax using specific Unicode characters for this syntax
itself.
There's no such statement in the UTR, even for longer term.
What is proposed instead is a way to *reference* (not define) graphics.
For the rest,
On 2015-06-02, William_J_G Overington wjgo_10...@btinternet.com wrote:
take place if people on this mailing list feel that it is a good
solution to the problem raised in section 8 of the following document.
http://www.unicode.org/reports/tr51/tr51-2.html
That section does not raise a
Responding to Philippe Verdy:
Nothing has been published.
It
has been published. It is published in this thread for discussion prior
to a possible submission to the Unicode Technical Committee that could
take place if people on this mailing list feel that it is a good
solution to the problem
On 6/2/2015 2:01 AM, William_J_G Overington wrote:
Local glyph memory, for use in compressing a document where the same
glyph is used two or more times in the document:
Um, that technology already exists. It is called a font.
A mechanism to be able to use the method to define a glyph
2015-06-01 1:33 GMT+02:00 Chris idou...@gmail.com:
Of course, anyone can invent a character set. The difficult bit is having
a standard way of combining custom character sets. That’s why a standard
would be useful.
And while stuff like this can, to some extent, be recognised by magic
On 5/31/2015 5:33 AM, Chris-as-John wrote:
Yes, Asmus good post. But I don’t really think HTML, even a subset, is
really the right solution.
The longer I think about this, what would be needed would be something
like an abstract format. A specification of the capabilities to be
supported
The abstract format already exists also for HTML (with MIME charset
extension of the media-type text/plain (it can also be embedded in a meta
tag, where the HTML source file ius just stored in a filesystem, so that a
webserver can parse it and provide the correct MIME header, if the
webserver has
David Starner wrote:
I would say that a system would conform with Unicode in having yellow
heart red (in a non-monochrome font) as well as if it made it a cross.
Either way it's violating character identity. I'd say that being
monochromatic is now like being monospaced; it's suboptimal for a
Of course, anyone can invent a character set. The difficult bit is having a
standard way of combining custom character sets. That’s why a standard would be
useful.
And while stuff like this can, to some extent, be recognised by magic numbers,
and unique strings in headers, such things are
John,
reading this discussion, I agree with your reaductio ad absurdum of
infinitely nested HTML.
But I think you are onto something with your hypothetical example of the
subset that works in ALL textual situations.
There's clearly a use case for something like it, and I believe many
Yes, Asmus good post. But I don’t really think HTML, even a subset, is really
the right solution. I’m reminded of the design for XML itself, it is supposed
to start with a header that defines what that XML will conform to. Those
definitions contain some unique identifiers of that XML schema,
2015-05-30 10:47 GMT+02:00 William_J_G Overington wjgo_10...@btinternet.com
:
Responding to Doug Ewell:
I think this cuts to the heart of what people have been trying to say
all along.
Historically, Unicode was not meant to be the means by which brand new
ideas are run up the proverbial
Note: Everything below is my personal opinion and does not represent any
official Unicode Consortium or UTC position.
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
Historically, Unicode was not meant to be the means by which brand
new ideas are run up the proverbial
I would say that a system would conform with Unicode in having yellow heart
red (in a non-monochrome font) as well as if it made it a cross. Either way
it's violating character identity. I'd say that being monochromatic is now
like being monospaced; it's suboptimal for a Unicode implementation,
Responding to Leo Broukhis:
A more common occurrence is the need to include a non-standard character in a
text message, be it a ski piste symbol or an obscure CJK ideogram. Have you
thought of embedding TrueType in Unicode?
Not congruently so, yet, in effect, yes, as I have considered
Responding to Doug Ewell:
I think this cuts to the heart of what people have been trying to say all
along.
Historically, Unicode was not meant to be the means by which brand new ideas
are run up the proverbial flagpole to see if they will gain traction.
History is interesting and can be a
Hmm, these once entities of which you speak, do they require javascript?
Because I'm not sure what we are looking for here is static documents requiring
a full programming language.
But let's say for a moment that html5 can, or could do the job here. Then to
make the dream come true that
Responding to Mark E. Shoulson:
As was pointed out to me, essentially what you are saying is you reject my
premise that one size does not fit all.
Well, I do not know where that came from, but no, I do not reject that premise.
There is plain text, there is HTML, there is XML.
HTML is
Responding to Philippe Verdy:
There's no advantage because what you want to create is effectively another
markup language with its own syntax (but requiring new obscure characters
that most applications and users will not be able to interpret and render
correctly in the way intended by you,
The format that I am suggesting would allow the image for a non-standard
emoji character to be included in a text message, with the image located at
the correct place in the text.
A more common occurrence is the need to include a non-standard
character in a text message, be it a ski piste
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
There's no advantage because what you want to create is effectively
another markup language with its own syntax (but requiring new
obscure characters that most applications and users will not be able
to interpret and
2015-05-29 4:37 GMT+02:00 John idou...@gmail.com:
Today the world goes very well with HTML(5) which is now the bext markup
language for document (including for inserting embedded images that don’t
require any external request”
If I had a large document that reused a particular character
As was pointed out to me, essentially what you are saying is you reject
my premise that one size does not fit all. You would prefer
*everything* be in plain text, so you wouldn't have to use other
formats for it. You're essentially converting plain text into THE
format for everything.
But
Today the world goes very well with HTML(5) which is now the bext markup
language for document (including for inserting embedded images that don’t
require any external request”
If I had a large document that reused a particular character thousands of
times, would this HTML markup require
Responding to Mark E. Shoulson:
The big advantage of this new format is that the result is an unambiguous
Unicode plain text file and could be placed within a file of plain text without
having to make the whole document a markup file to some format. Plain text is
the key advantage.
The
Doug,
Read on in the minutes to the next day. 143-C27 and related actions.
There are a few things to keep in mind here.
1. The un-deprecation of the tags U+E0020..U+E007E *is* part of
the UCD for Unicode 8.0. The change has already taken place in
the revised beta files now posted (see
Ken Whistler kenwhistler at att dot net wrote:
Read on in the minutes to the next day. 143-C27 and related actions.
Ah. Thank you. Now I understand what Steven meant by read the minutes,
too.
That's the problem with reading individual items in meeting minutes:
each item is a snapshot in time,
; eric.mul...@efele.net;
asmus-...@ix.netcom.com
Subject: Re: Tag characters
Peter Constable wrote as follows:
Would Unicode really want to get into the business of running a UFL service?
Well, Unicode is about precision, interoperability and long-term stability,
and, given, in relation to one
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
Please feel free to suggest improvements.
http://en.wikipedia.org/wiki/Scalable_Vector_Graphics
--
Doug Ewell | http://ewellic.org | Thornton, CO
Thanks Ken; and yes Doug; http://www.unicode.org/L2/L2015/15107.htm#143-C27 was
the reference I was looking for when I wrote my too- brief reply earlier. My
apologies.
S
Enviado desde nuestro iPhone.
On May 27, 2015, at 2:06 PM, Doug Ewell d...@ewellic.org wrote:
Ken Whistler kenwhistler
I think I've figured out the philosophy WJGO is trying to follow here.
We should have a way to encode graphics in Unicode
We should have a way to encode programming instructions in Unicode
How about
We should have a way to encode sound-waves in Unicode?
Or
We should have a way to encode *moving*
Peter Constable wrote as follows:
Would Unicode really want to get into the business of running a UFL service?
Well, Unicode is about precision, interoperability and long-term stability,
and, given, in relation to one particular specified base character followed by
some tag characters, that a
On 5/21/2015 1:25 PM, Asmus Freytag (t)
wrote:
On 5/21/2015 8:46 AM, Peter Constable
wrote:
Would
Unicode really want to get into the business of running a
UFL
Aww... I was SURE you meant UFOs!
On 2015-05-26 09:48, Eric Muller wrote:
On 5/21/2015 1:25 PM, Asmus Freytag (t) wrote:
On 5/21/2015 8:46 AM, Peter Constable wrote:
Would Unicode really want to get into the business of running a UFL
service?
I suspect both Eric and I may have have been
[mailto:unicode-boun...@unicode.org] *On Behalf Of
*Asmus Freytag (t)
*Sent:* Wednesday, May 20, 2015 10:15 PM
*To:* Eric Muller; unicode@unicode.org
*Subject:* Re: Tag characters
On 5/20/2015 9:57 PM, Eric Muller wrote:
On 5/20/2015 7:11 PM, Doug Ewell wrote:
In any event, URLs
I don’t think so.
Sincerely, Erkki
Lähettäjä: Unicode [mailto:unicode-boun...@unicode.org] Puolesta Peter Constable
Lähetetty: 21. toukokuuta 2015 18:46
Vastaanottaja: Asmus Freytag (t); Eric Muller; unicode@unicode.org
Aihe: RE: Tag characters
Would Unicode really want to get
Would Unicode really want to get into the business of running a UFL service?
P
From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Asmus Freytag
(t)
Sent: Wednesday, May 20, 2015 10:15 PM
To: Eric Muller; unicode@unicode.org
Subject: Re: Tag characters
On 5/20/2015 9:57 PM, Eric
2015-05-21 4:11 GMT+02:00 Doug Ewell d...@ewellic.org:
Philippe Verdy wrote:
URLs were initially deisgned to be stable (and this is still a strong
recommendation).
[+ 559 words]
It doesn't matter if they were designed to be stable. Users don't keep
them stable.
I can't believe we're
Peter Constable wrote as follows.
Evidently there were more than two type of people. There are those who feel
50 years is long enough; there are others who feel that five years is long
enough; there are likely others that feel 75 or 30 or some other values are
long enough. Then there are
Well for now a reasonnably stable standard exists: URLs, that can point to
a collection of pagenames (each site can choose its own registry to
name/encode the flags)
URLs are then returening images (you can make a site that can return images
in several formats and with variable sizes as well or
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
Well for now a reasonnably stable standard exists: URLs, that can
point to a collection of pagenames (each site can choose its own
registry to name/encode the flags)
URLs are the opposite of stability. Anyone can post whatever they
On Wed, 20 May 2015 17:15:28 -0700
Asmus Freytag (t) asmus-...@ix.netcom.com wrote:
Have there been any discussions of the flag alphabet? (Signal flags).
It seems to me that when schemes for representing sets of flags are
discussed, it would be useful to keep open the ability to use the
URLs were initially deisgned to be stable (and this is still a strong
recommendation).
However I did not describe just URLs but URNs (whose URLs are just
resolvers locating them).
URNs share with URLs (and URIs in general, as well the UCS) the initial U
which is intended to be universal (both in
, 2015 6:08 PM
To: unicode@unicode.org
Subject: Re: Tag characters
On Wed, 20 May 2015 17:15:28 -0700
Asmus Freytag (t) asmus-...@ix.netcom.com wrote:
Have there been any discussions of the flag alphabet? (Signal flags).
It seems to me that when schemes for representing sets of flags
Have there been any discussions of the flag alphabet? (Signal flags).
They are not that infrequently used online or in print, although the
concentration tends to be higher in publications/sites geared to
nautical audiences (not that different from chess pieces and chess
publications).
Now,
On Wed, 20 May 2015 17:29:28 +0100 (BST)
William_J_G Overington wjgo_10...@btinternet.com wrote:
This could also be of use now so as to display such items as the flag
of the USA at various historical periods. It would be helpful if a
particular year were chosen for normalization purposes: for
On 5/20/2015 9:57 PM, Eric Muller wrote:
On 5/20/2015 7:11 PM, Doug Ewell wrote:
In any event, URLs that point to images would be an awful basis for
an encoding.
I would make an exception for the URL
http://unicode.org/Public/8.0.0/ucd/StandardizedFlags.html.
Eric.
Currently that gives
...@unicode.org] On Behalf Of Richard
Wordingham
Sent: Wednesday, May 20, 2015 6:08 PM
To: unicode@unicode.org
Subject: Re: Tag characters
On Wed, 20 May 2015 17:15:28 -0700
Asmus Freytag (t) asmus-...@ix.netcom.com wrote:
Have there been any discussions of the flag alphabet? (Signal flags).
It seems
On 5/20/2015 7:11 PM, Doug Ewell wrote:
In any event, URLs that point to images would be an awful basis for an
encoding.
I would make an exception for the URL
http://unicode.org/Public/8.0.0/ucd/StandardizedFlags.html.
Eric.
length is probably
not long enough.
Peter
-Original Message-
From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Doug Ewell
Sent: Tuesday, May 19, 2015 10:01 AM
To: Unicode Mailing List
Cc: William_J_G Overington
Subject: Re: Tag characters
William_J_G Overington wjgo underscore
2015-05-19 7:18 GMT+02:00 Mark Davis ☕️ m...@macchiato.com:
There is a difference between EU and UN; the former is in BCP47. That
being said, we could look at making the exceptionally reserved codes valid
for this purpose (or at least the UN code). It appears that there are only
3
Re: Tag characters
Mark Davis ⛾ mark at macchiato dot com wrote:
A more concrete proposal will be in a PRI to be issued soon, and
people will have a chance to comment more then.
I'll hold off on most other questions until the PRI appears.
The principal reason for 3 digit codes is because
Doug Ewell wrote:
Hopefully the MA will adhere to the new 50-year limit. The example given
in the proposal talked about trans-national flags.
What is MA please?
A 50-year limit seems far too short a time. With that figure, a document could
have its meaning retrospectively changed at least
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
Hopefully the MA will adhere to the new 50-year limit.
What is MA please?
Maintenance Agency:
http://www.iso.org/iso/home/standards/country_codes.htm
A 50-year limit seems far too short a time.
There are two types of
A few notes.
A more concrete proposal will be in a PRI to be issued soon, and people
will have a chance to comment more then. (I'm not trying to discourage
discussion, just pointing out that there will be something more concrete
relatively soon to comment on—people are pretty busy getting 8.0
2015-05-16 19:07 GMT+02:00 Doug Ewell d...@ewellic.org:
L2/15-145R says:
On some platforms that support a number of emoji flags, there is
substantial demand to support additional flags for the following:
[...]
Certain supra-national regions, such as Europe (European Union flag)
or the
See the meeting minutes and the actual utr51.
Enviado desde nuestro iPhone.
El may 16, 2015, a las 10:07 AM, Doug Ewell d...@ewellic.org escribió:
L2/15-145R says:
On some platforms that support a number of emoji flags, there is
substantial demand to support additional flags for the
Steven R. Loomis wrote:
See the meeting minutes and the actual utr51.
Sorry, I didn't find anything dealing with numeric codes in Section
E.1.3 of the meeting minutes, and the copy of UTR #51 at unicode.org
doesn't appear to have been updated for anything beyond the existing
RIS. What
Of Peter Constable
Sent: Friday, May 15, 2015 8:47 AM
To: Shervin Afshar
Cc: unicode@unicode.org
Subject: RE: Future of Emoji? (was Re: Tag characters)
MSN Messenger supported extensible stickers years ago. A couple of sites still
offering add-ons:
http://www.getsmile.com/
http://www.smileys4msn.com
Subject: Re: Future of Emoji? (was Re: Tag characters)
Good point. I missed these while looking into compatibility symbols. Of course,
as with Yahoo[1] and MSN[2] Messenger emoji sets, most of these are mappable to
current or proposed sets of Unicode emoji (e.g. Lips Sealed ≈ U+1F910
ZIPPER-MOUTH
[mailto:unicode-boun...@unicode.org] *On Behalf Of *Shervin
Afshar
*Sent:* Thursday, May 14, 2015 2:27 PM
*To:* wjgo_10...@btinternet.com
*Cc:* unicode@unicode.org
*Subject:* Re: Tag characters
Thinking about this further, could the technique be used to solve the
requirements of
section 8 Longer
And to put Mark's comments in some statistical perspective, in the context
of all the media hype, the true big bang for emoji in Unicode was
Version 6.0,
released over 4-1/2 years ago now. *That* was the Unicode release that added
hundreds and hundreds of emoji for Japanese carrier
*Subject:* RE: Future of Emoji? (was Re: Tag characters)
MSN Messenger supported extensible stickers years ago. A couple of sites
still offering add-ons:
http://www.getsmile.com/
http://www.smileys4msn.com/
Peter
*From:* Shervin Afshar [mailto:shervinafs...@gmail.com
What else would be possible if the same sort of technique were applied to
another base character?
Thinking about this further, could the technique be used to solve the
requirements of
section 8 Longer Term Solutions
of
http://www.unicode.org/reports/tr51/tr51-2.html
?
Both colour pixel map and
http://www.unicode.org/L2/L2015/15107.htm
points indirectly to:
http://www.unicode.org/L2/L2015/15145r-add-regional-ind.pdf
which says:
The proposal has two parts
1. Un-deprecate TAG characters E0020-E007E.
Hee hee.
Hee hee.
2. Define a character as the “base” for a following sequence
Thinking about this further, could the technique be used to solve the
requirements of
section 8 Longer Term Solutions
IMO, the industry preferred longer term solution (which is also discussed
in that section with few existing examples) for emoji, is not going to be
based on characters.
↪
]
Sent: Thursday, May 14, 2015 8:12 PM
To: Peter Constable
Cc: unicode@unicode.org
Subject: Future of Emoji? (was Re: Tag characters)
Peter,
This very topic was discussed in last meeting of the subcommittee and my
impression is that there are plans to promote the use of embedded graphics (aka
:27 PM
*To:* wjgo_10...@btinternet.com
*Cc:* unicode@unicode.org
*Subject:* Re: Tag characters
Thinking about this further, could the technique be used to solve the
requirements of
section 8 Longer Term Solutions
IMO, the industry preferred longer term solution (which is also discussed
, 2015 8:12 PM
*To:* Peter Constable
*Cc:* unicode@unicode.org
*Subject:* Future of Emoji? (was Re: Tag characters)
Peter,
This very topic was discussed in last meeting of the subcommittee and my
impression is that there are plans to promote the use of embedded graphics
(aka stickers
, 2015 2:27 PM
To: wjgo_10...@btinternet.com
Cc: unicode@unicode.org
Subject: Re: Tag characters
Thinking about this further, could the technique be used to solve the
requirements of
section 8 Longer Term Solutions
IMO, the industry preferred longer term solution (which is also discussed
I remembered that I produced a font with visible glyphs for the tag characters.
Some readers might like a copy of the font, free, from the following forum post.
http://forum.high-logic.com/viewtopic.php?p=10587#p10587
I have been trying the font out again and find that I can, with the font
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
I feel that deprecating the tag characters within Unicode was a
mistake.
There aren't many times when I agree with William, but this is one of
them.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
97 matches
Mail list logo
