the *format* of the strings, not
their *repertoire*. That is, should the string be “Arrival: %s” or “Arrival:
${date}” or “Arrival: {0}”?
Does that answer your question?
--
Steven R. Loomis | @srl295 | git.io/srl295
El ene. 10, 2020, a las 2:48 p. m., James Kass via Unicode
escribió
* sentences
On 2020-01-10 10:48 PM, James Kass wrote:
On 2020-01-10 9:55 PM, announceme...@unicode.org wrote:
But until now we have not had a syntax for localizable message
strings standardized by Unicode.
What is the difference between “localizable message strings” and
“localized
On 2020-01-10 9:55 PM, announceme...@unicode.org wrote:
But until now we have not had a syntax for localizable message strings
standardized by Unicode.
What is the difference between “localizable message strings” and
“localized sentances”? Asking for a friend.
On 2020-01-04 12:50 PM, Richard Wordingham via Unicode wrote:
dev2: कः꣡
dev3: क꣡ः
Grantha: (1) ጕ፧ጃ
(2) ጕጃ፧
The second Grantha spelling is enabled by a Harfbuzz-only change to
the USE categorisations. It treats Grantha visarga and spacing
anusvara as though inpc=Top rather than
On 2020-01-02 1:04 AM, Richard Wordingham wrote in a thread deriving
from this one,
> Have you found a definition of the ISCII handling of Vedic characters?
No. It would be helpful. ISCII apparently wasn't really used much. It
would also be helpful to know the encoding order in any
On 2020-01-01 8:11 PM, James Kass wrote:
It’s too bad that ISCII didn’t accomodate the needs of Vedic Sanskrit,
but here we are.
Sorry, that might be wrong to say. It's possible that it's Unicode's
adaptation of ISCII that hinders Vedic Sanskrit.
On 2020-01-01 11:17 AM, Richard Wordingham via Unicode wrote:
> That's exactly the sort of mess that jack-booted renderers are trying
> to minimise. Their principle is that there should be only one encoding
> per shape, though to be fair:
>
> 1) some renderers accept canonical equivalents.
>
A workaround until some kind of satisfactory adjustment is made might be
to simply use COLON for VISARGA. Or...
VISARGA ⇒ U+02F8 MODIFIER LETTER RAISED COLON
ANUSVARA⇒U+02D9 DOT ABOVE
...as long as the font(s) included both those characters.
य॑ यॆ॑
य॑ं -- anusvara last
यॆ॑ं -- "
य॑: --
On 2019-12-21 6:27 AM, Shriramana Sharma via Unicode wrote:
However, even the simplest Vedic sequence (not involving Sama Vedic or
multiple tone marker combinations) like दे॒वेभ्य॑ः throws up a dotted
circle, and one is expected (see developer feedback in that bug
report) to input the visarga
On 2019-12-21 2:43 AM, Shriramana Sharma via Unicode wrote:
Ohkay and that's very nice meaningful feedback from actual
developer+user interaction. So the way I look at this going forward is
that we have four options:
1)
With the existing single NBSP character, provide a software option to
From our colleague’s web site,
http://jkorpela.fi/chars/spaces.html
“On web browsers, no-break spaces tended to be non-adjustable, but
modern browsers generally stretch them on justification.”
Jukka Korpela then offers pointers about avoiding unwanted stretching.
and
“The change in the
On 2019-12-17 12:50 AM, Shriramana Sharma via Unicode wrote:
I would have gone and filed this as a LibreOffice bug since that's the
software I use most, but when I found this is a cross-software
problem, I thought it would be best to have this discussed and
documented here (and in a future
On 2019-12-18 12:42 PM, Marius Spix via Unicode wrote:
Unicode has a HEAVY PLUS SIGN (U+2795) and a HEAVY MINUS SIGN (U+2796).
I wonder, if a HEAVY EQUALS SIGN could complete that character set.
This would allow emoji phrases like ➕= ❤️. (man plus cat equals
love) looking typographically
U+0020 SPACE
U+00A0 NO-BREAK SPACE
These two characters are equal in every way except that one of them
offers an opportunity for a line break and the other does not.
If the above statement is true, then any conformant application must
treat/process/display both characters identically.
Asmus Freytag wrote,
> And any recommendation that is not compatible with what the overwhelming
> majority of software has been doing should be ignored (or only
enabled on
> explicit user input).
>
> Otherwise, you'll just advocating for a massively breaking change.
It seems like the
On 2019-12-17 10:37 AM, QSJN 4 UKR via Unicode wrote:
Agree.
By the way, it is common practice to use multiple nbsp in a row to
create a larger span. In my opinion, it is wrong to replace fixed
width spaces with non-breaking spaces.
Quote from Microsoft Typography Character design standards:
On 2019-12-03 12:59 AM, Richard Wordingham via Unicode wrote:
On Mon, 2 Dec 2019 12:01:52 +
"Costello, Roger L. via Unicode" wrote:
From the book titled "Computer Power and Human Reason" by Joseph
Weizenbaum, p.74-75
Suppose that the alphabet with which we wish to concern ourselves
On 2019-11-19 11:00 PM, Mark E. Shoulson via Unicode wrote:
Why so concerned with these minutiæ? Were you in fact misled?
(Doesn't sound like it.) Do you know someone who was, or whom you
fear would be? What incorrect conclusions might they draw from that
misunderstanding, and how serious
On 2019-11-19 6:59 PM, Costello, Roger L. via Unicode wrote:
Today I received an email from the Unicode organization. The email said this:
(italics and yellow highlighting are mine)
The Unicode Standard is the foundation for all modern software and
communications around the world, including
On 2019-11-13 3:00 AM, Asmus Freytag via Unicode wrote:
The current effort starts from an unrelated problem (Unicode not wanting to
administer emoji applications) and in my analysis, seriously puts the cart
before the horse.
But it does solve the unrelated problem.
There's nothing stopping
On 2019-09-27 5:15 AM, Fred Brennan via Unicode wrote:
I only have two lingering questions.
* Does the existence of the legacy Adobe encoding Adobe-Japan1-6 shift the
balance? It has a SQUARE TB at CID+8306.
https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5078.Adobe-Japan1-6.pdf
Well, it was intended to be off list. It seems that this has been
mentioned before, for example;
http://www.unicode.org/mail-arch/unicode-ml/y2011-m07/0029.html
Maybe it's time for a new thread/subject title?
On 2019-08-21 2:40 AM, James Kass wrote:
Are we are allowed to write Llangollen as the definition of the
Unicode Collation Algorithm implies we should, with an invisible CGJ
between the 'n' and the 'g', so that it will collate correctly in
Welsh? That CGJ is necessary so that it will collate
On 2019-08-21 2:08 AM, Richard Wordingham via Unicode wrote:
Are we are allowed to write Llangollen as the definition of the
Unicode Collation Algorithm implies we should, with an invisible CGJ
between the 'n' and the 'g', so that it will collate correctly in
Welsh? That CGJ is necessary so
On 2019-08-15 12:25 AM, Asmus Freytag via Unicode wrote:
Empirically, it has been observed that some distinctions that are claimed by
users, standards developers or implementers were de-facto not honored by type
developers (and users selecting fonts) as long as the native text doesn't
contain
On 2019-08-14 7:50 PM, Richard Wordingham via Unicode wrote:
I think you'd also have to change the reference glyph of LATIN LOWER
CASE I WITH HEART to show a heart. That's valid because the UCD trumps
the code charts, and and no Unicode-compliant process may deliberately
render differently
On 2019-08-12 8:30 AM, Andrew West wrote:
This issue was discussed at WG2 in 2013
(https://www.unicode.org/L2/L2013/13128-latvian-marshal-adhoc.pdf),
when there was a recommendation to encode precomposed letters L and N
with cedilla*with no decomposition*, but that solution does not seem
to
On 2019-08-11 5:26 PM, [ Doug Ewell ] via Unicode wrote:
If you are thinking of these as potential future additions to the standard,
keep in mind that accented letters that can already be represented by a
combination of letter + accent will not ever be encoded. This is one of the
On 2019-08-11 4:07 AM, Robert Wheelock via Unicode wrote:
Hello!
I remember that a website that has tables for certain PUA precomposed
accented characters that aren’t yet in Unicode (thing like: Marshallese
M/m-cedilla, H/h-acute, capital T-dieresis, capital H-underbar, acute
accented
https://en.wikipedia.org/wiki/Israeli_new_shekel
"With the issuing of the third series, the Bank of Israel has adopted
the standard English spelling of shekel and plural shekels for its
currency.[30] Previously, the Bank had formally used the Hebrew
transcriptions of sheqel and sheqalim
On 2019-04-26 11:08 PM, Doug Ewell via Unicode wrote:
This is a small percentage of the number of fonts that have all four of these
Armenian glyphs, but show the abbreviation mark as a spacing glyph. It looks
like Unicode is right, Wikipedia is right, and the fonts are wrong.
If the
The Guara Times font maps Cyrillic letters (Л,л,М,м) with chandrabindus
in the P.U.A. of the font. This can be done without the P.U.A. using
U+0310: Л̐,л̐,М̐,м̐
http://www.chakra.lv/blog/2016/10/19/transliterating-sanskrit-into-russian/
On 2019-04-18 7:59 PM, Richard Wordingham via
Confirming that the installed version here shows psi. (Version 5.74)
Luc(as) de Groot is the type designer, I've copied him on this message.
On 2019-04-17 10:06 PM, Hans Åberg via Unicode wrote:
You are possibly both right, because it is OK in the web font but wrong in the
desktop font.
> Perhaps that debunking was in the very book
> cited by Martin J. Dürst earlier in this thread.
Yes, starting on page 24.
https://books.google.com/books?id=hypplIDMd0IC=PA24=isbn:0824812077+Yukaghir=en=X=0ahUKEwj1n4r719zgAhWJn4MKHcdyCHIQ6AEIKjAA#v=onepage=isbn%3A0824812077%20Yukaghir=false
>
http://historyview.blogspot.com/2011/10/yukaghir-girl-writes-love-letter.html
According to a comment, the Yukaghir love letter as semasiographic
communication was debunked by John DeFrancis in 1989 who asserted that
it was merely a prop in a Yukaghir parlor game. Perhaps that debunking
On 2019-04-16 7:09 AM, Martin J. Dürst via Unicode wrote:
All the examples you cite, where images stand for sounds, are typically
used in some of the oldest "ideographic" scripts. Egyptian definitely
has such concepts, and Han (CJK) does so, too, with most ideographs
consisting of a semantic
On 2019-04-16 3:18 AM, Mark E. Shoulson via Unicode wrote:
> For whatever reason, the author decided to go with ️ for "God" and
such, ...
"OM"igod.
Just a thought.
If the emoji OM SYMBOL is to be used for "god", shouldn't it be casing
to enable distinction between the common noun and
On 2019-01-24 Andrew West wrote,
> The ESC and UTC do an appallingly bad job at regulating emoji, and I
> would like to see the Emoji Subcommittee disbanded, and decisions on
> new emoji taken away from the UTC, and handed over to a consortium or
> committee of vendors who would be given a
Philippe Verdy wrote,
>>> case mappings,
>>
>> Adjust them as needed.
>
> Not so easy: case mappings cannot be fixed. They are stabilized in
Unicode.
> You would need special casing rules under a specific "locale" for maths.
In BabelPad, I can select a string of text and convert it to math
On 2019-02-11 6:42 PM, Kent Karlsson wrote:
> Using a VS to get italics, or anything like that approach, will
> NEVER be a part of Unicode!
Maybe the crystal ball is jammed. This can happen, especially on the
older models which use vacuum tubes.
Wanting a second opinion, I asked the magic
Philippe Verdy wrote,
>> ...[one font file having both italic and roman]...
> The only case where it happens in real fonts is for the mapping of
> Mathematical Symbols which have a distinct encoding for some
> variants ...
William Overington made a proof-of-concept font using the VS14
Martin J. Dürst wrote,
>> Isn't that already the case if one uses variation sequences to choose
>> between Chinese and Japanese glyphs?
>
> Well, not necessarily. There's nothing prohibiting a font that includes
> both Chinese and Japanese glyph variants.
Just as there’s nothing prohibiting a
Asmus Freytag wrote,
> You are still making the assumption that selecting a different glyph for
> the base character would automatically lead to the selection of a
different
> glyph for the combining mark that follows. That's an iffy assumption
> because "italics" can be realized by choosing
William,
Rather than having the user insert the VS14 after every character, the
editor might allow the user to select a span of text for italicization.
Then it would be up to the editor/app to insert the VS14s where appropriate.
For Andrew’s example of “fête”, the user would either type
William Overington wrote,
> Well, a proposal just about using VS14 to indicate a request for an
> italic version of a glyph in plain text, including a suggestion of to
> which characters it could apply, would test whether such a proposal
> would be accepted to go into the Document Register for
Philippe Verdy responded to William Overington,
> the proposal would contradict the goals of variation selectors and would
> pollute ther variation sequences registry (possibly even creating
conflicts).
> And if we admit it for italics, than another VSn will be dedicated to
bold,
> and
On 2019-01-28 8:58 PM, Richard Wordingham wrote:
> On Mon, 28 Jan 2019 03:48:52 +
> James Kass via Unicode wrote:
>
>> It’s been said that the text segmentation rules seem over-complicated
>> and are probably non-trivial to implement properly. I tried your
>>
On 2019-01-31 3:18 PM, Adam Borowski via Unicode wrote:
> They're only from a spammer's point of view.
Spammers need love, too. They’re just not entitled to any.
David Starner wrote,
> The choice of using single-byte character sets isn't always voluntary.
> That's why we should use ISO-2022, not Unicode. Or we can expect
> people to fix their systems. What systems are we talking about, that
> support Unicode but compel you to use plain text? The use of
David Starner wrote,
> Emoji, as have been pointed out several times, were in the original
> Unicode standard and date back to the 1980s; the first DOS character
> page has similes at 0x01 and 0x02.
That's disingenuous.
David Starner wrote,
>> ... italics, bold, strikethrough, and underline in plain-text
>
> Okay? Ed can do that too, along with nano and notepad. It's called
> HTML (TeX, Troff). If by plain-text, you mean self-interpeting,
> without external standards, then it's simply impossible.
HTML source
Doug Ewell wrote,
> I can't speak for Andrew, but I strongly suspect he implemented this as
> a proof of concept, not to declare himself the Maker of Standards.
BabelPad also offers plain-text styling via math-alpha conversion,
although this feature isn’t newly added. Users interested in
On 2019-01-29 5:10 PM, Doug Ewell via Unicode wrote:
I thought we had established that someone had mentioned it on this list,
at some time during the past three weeks. Can someone look up what post
that was? I don't have time to go through scores of messages, and there
is no search facility.
On 2019-01-29 1:55 AM, Mark E. Shoulson via Unicode wrote:
I guess "Suck it up and deal with it." And that may indeed be the answer.
It would certainly make for shorter and simpler FAQ pages, anyway.
On 2019-01-28 7:31 AM, Mark Davis ☕️ via Unicode wrote:
Expecting people to type in hard-to-find invisible characters just to
correct double-click is not a realistic expectation.
True, which is why such entries, when consistent, are properly handled
at the keyboard driver level. It's a
On 2019-01-27 11:38 PM, Richard Wordingham via Unicode wrote:
On Sun, 27 Jan 2019 19:57:37 +
James Kass via Unicode wrote:
On 2019-01-27 7:09 PM, James Tauber via Unicode wrote:
In my original post, I asked if a language-specific tailoring of
the text segmentation algorithm
On 2019-01-27 11:44 PM, Philippe Verdy wrote:
> You're not very explicit about the Tag encoding you use for these styles.
This bold new concept was not mine. When I tested it
here, I was using the tag encoding recommended by the developer.
> Of course it must not be a language tag
A new beta of BabelPad has been released which enables input, storing,
and display of italics, bold, strikethrough, and underline in plain-text
using the tag characters method described earlier in this thread. This
enhancement is described in the release notes linked on this download page:
On 2019-01-27 7:09 PM, James Tauber via Unicode wrote:
In my original post, I asked if a language-specific tailoring of the
text segmentation algorithm was the solution but no one here has
agreed so far.
If there are likely to be many languages requiring exceptions to the
segmentation
On 2019-01-27 3:08 PM, Tom Gewecke via Unicode wrote:
I think the Unicode Hawaiian ʻokina is supposed to be U+02BB (instead
of U+02BC).
notes for U+02BB
* typographical alternate for 02BD or 02BF
* used in Hawai'ian orthorgraphy as 'okina (glottal stop)
Richard Wordingham responded to Michael Everson,
>> I’ll be publishing a translation of Alice into Ancient Greek in due
>> course. I will absolutely only use U+2019 for the apostrophe. It
>> would be wrong for lots of reasons to use U+02BC for this.
>
> Please list them.
Let's see the list of
Richard Wordingham replied to Asmus Freytag,
>> To make matters worse, users for languages that "should" use U+02BC
>> aren't actually consistent; much data uses U+2019 or U+0027. Ordinary
>> users can't tell the difference (and spell checkers seem not
>> successful in enforcing the practice).
Perhaps I'm not understanding, but if the desired behavior is to
prohibit both line and word breaks in the example string, then...
In Notepad, replacing U+0020 with U+00A0 removes the line-break.
U+0020 ( δ’ αρχαια )
U+00A0 ( δ’ αρχαια )
U+202F ( δ’ αρχαια )
It also changes the advancement
Mark Davis responded to Asmus Freytag,
>> breaking selection for "d'Artagnan" or "can't" into two is overly fussy.
>
> True, and that is not what U+2019 does; it does not break medially.
Mark Davis earlier posted this example,
> So something like "δ’ αρχαια" (picking a phrase at random) would
On 2019-01-25 10:06 PM, Asmus Freytag via Unicode wrote:
James, by now it's unclear whether your ' is 2019 or 02BC.
The example word "aren't" in previous message used U+2019. Sorry if I
was unclear.
On 2019-01-26 12:18 AM, Asmus Freytag (c) responded:
On 1/25/2019 3:49 PM, Andrew Cunningham wrote:
Assuming some mechanism for italics is added to Unicode, when
converting between the new plain text and HTML there is insufficient
information to correctly convert to HTML. many elements may
For U+2019, there's a note saying 'this is the preferred character to
use for apostrophe'.
Mark Davis wrote,
> When it is between letters it doesn't cause a word break, ...
Some applications don't seem to get that. For instance, the
spellchecker for Mozilla Thunderbird flags the string
> Maybe I should have said emoji are fan-driven.
That works. Here's the previous assertion rephrased:
We should no more expect the conventional Unicode character encoding
model to apply to emoji than we should expect the old-fashioned text
ranges to become fan-driven.
And if we don't
Andrew West wrote,
> Why should we not expect the conventional Unicode character encoding
> mode to apply to emoji?
Remember when William Overington used to post about encoding colours,
sometimes accompanied by novel suggestions about how they could be
encoded or referenced in plain-text?
Andrew West wrote,
> ...
> http://www.unicode.org/L2/L2018/18208-white-wine-rgi.pdf), just an
> assertion that it would be a good idea if emoji users could add a
> colored swatch to an existing emoji to indicate what color they want
> it to represent (note that the colored characters do not
Nobody has really addressed Andrew West's suggestion about using the tag
characters.
It seems conformant, unobtrusive, requiring no official sanction, and
could be supported by third-partiers in the absence of corporate
interest if deemed desirable.
One argument against it might be:
David Starner wrote,
> You're emailing from Gmail, which has support for italics in email.
But I compose e-mails in BabelPad, which has support for far more than
italics in HTML mail. And I'm using Mozilla Thunderbird to send and
receive text e-mail via the Gmail account.
And if I wanted
Responding to David Starner,
It’s true that most users can’t be troubled to take the extra time
needed to insert any kind of special characters which aren’t covered by
the keyboard. Even the enthusiasts among us seldom take the trouble to
include ‘proper’ quotes and apostrophes in e-mails
On 2019-01-20 10:49 PM, Garth Wallace wrote:
I think the real solution is for Twitter to just implement basic
styling and make this a moot point.
At which time it would only become a moot point for Twitter users.
There's also Facebook and other on-line groups. Plus scholars and
(In the event that a persuasive proposal presentation prompts the
possibility of italics encoding...)
Possible approaches include:
1 - Liberating the italics from the Members Only Math Club
...which has been an ongoing practice since they were encoded. It
already works, but the set is
Victor Gaultney wrote,
> If however, we say that this "does not adequately consider the harm done
> to the text-processing model that underlies Unicode", then that exposes a
> weakness in that model. That may be a weakness that we have to accept for
> a variety of reasons (technical
On 2019-01-19 6:19 PM, wjgo_10...@btinternet.com wrote:
> It seems to me that it would be useful to have some codes that are
> ordinary characters in some contexts yet are control codes in others, ...
Italics aren't a novel concept. The approach for encoding new
characters is that
Marcel Schneider wrote,
> When you ask for knowing the foundations and that knowledge is
persistently refused,
> you end up believing that those foundations just can’t be told.
>
> Note, too, that I readily ceased blaming UTC, and shifted the blame
elsewhere, where it
> actually belongs
For web searching, using the math-string 푀푎푦푛푎푟푑 퐾푒푦푛푒푠 as
the keywords finds John Maynard Keynes in web pages. Tested this in
both Google and DuckDuckGo. Seems like search engines are accomodating
actual user practices. This suggests that social media data is possibly
already being
On 2019-01-17 11:50 AM, Martin J. Dürst wrote:
> Most probably not. I think Asmus has already alluded to it, but in good
> typography, roman and italic fonts are considered separate.
So are Latin and Cyrillic fonts. So are American English and Polish
fonts, for that matter, even though
On 2019-01-17 6:27 AM, Martin J. Dürst replied:
> ...
> So even if you can find examples where the presence or absence of
> styling clearly makes a semantic difference, this may or will not be
> enough. It's only when it's often or overwhelmingly (as opposed to
> occasionally) the case that a
Victor Gaultney wrote,
> Treating italic like punctuation is a win for a lot of people:
Italic Unicode encoding is a win for a lot of people regardless of
approach. Each of the listed wins remains essentially true whether
treated as punctuation, encoded atomically, or selected with VS.
>
Julian Bradfield wrote,
> Oh, and what about dropped initials? They have been used in both
> manuscripts and typography for many centuries - surely we must encode
> them?
Naa-aah, we just hack the full width presentation forms for that.
Ｄrop Ｃaps in Ｐlain Ｔext
(Whether they actually drop
Responding to David Starner,
> I might complain about the people who claim to like plain text yet would
> only be happy with massive changes to it, though.
Most movie lovers welcomed talkies.
People are free to cling to their rotary phones as long as they like.
They just can't press the
Victor Gaultney wrote,
> Use of variation selectors, a single character modifier, or combining
> characters also seem to be less useful options, as they act at the
individual
> character level and are highly impractical. They also violate the key
concept
> that italics are a way of marking a
Enabling plain-text doesn't make rich-text poor.
People who regard plain-text with derision, disdain, or contempt have
every right to hold and share opinions about what plain-text is *for*
and in which direction it should be heading. Such opinions should
receive all the consideration they
Although there probably isn't really any concerted effort to "keep
plain-text mediocre", it can sometimes seem that way.
As we've been told repeatedly, just because something has been done over
and over again doesn't mean that there's a precedent for it.
Using spans of text as a general
Hans Åberg wrote,
> How about using U+0301 COMBINING ACUTE ACCENT: 푝푎푠푠푒́
Thought about using a combining accent. Figured it would just display
with a dotted circle but neglected to try it out first. It actually
renders perfectly here. /That's/ good to know. (smile)
ore his...)
Best regards,
James Kass
Not a twitter user, don't know how popular the practice is, but here's a
couple of links concerned with how to use bold or italics in Twitter
plain text messages.
https://www.simplehelp.net/2018/03/13/how-to-use-bold-and-italicized-text-on-twitter/
https://mothereff.in/twitalics
Both pages
Julian Bradfield wrote,
> I have never seen a Unicode math alphabet character in email
> outside this list.
It's being done though. Check this message from 2013 which includes the
following, copy/pasted from the web page into Notepad:
혗혈혙혛 혖혍 헔햳햮헭.향햱햠햬햤햶햮햱햪 © ퟮퟬퟭퟯ 햠햫햤햷 햦햱햠햸
Martin J. Dürst wrote,
> I'd say it should be conservative. As the meaning of that word
> (similar to others such as progressive and regressive) may be
> interpreted in various way, here's what I mean by that.
>
> It should not take up and extend every little fad at the blink of an
> eye. It
Marcel Schneider wrote,
> There is a crazy typeface out there, misleadingly called 'Courier New',
> as if the foundry didn’t anticipate that at some point it would be better
> called "Courier Obsolete". ...
퐴푟푡 푛표푢푣푒푎푢 seems a bit 푝푎푠푠é nowadays, as well.
(Had to use mark-up for that “span”
Julian Bradfield replied,
>> Sounds like you didn't try it. VS characters are default ignorable.
>
> By software that has a full understanding of Unicode. There is a very
> large world out there of software that was written before Unicode was
> dreamed of, let alone popular.
यदि आप किसी
Mark E. Shoulson wrote,
> This discussion has been very interesting, really. I've heard what I
> thought were very good points and relevant arguments from both/all
> sides, and I confess to not being sure which I actually prefer.
It's subjective, really. It depends on how one views
On 2019-01-12 4:26 PM, wjgo_10...@btinternet.com wrote:
I have now made, tested and published a font, VS14 Maquette, that uses
VS14 to indicate italic.
https://forum.high-logic.com/viewtopic.php?f=10=7831=37561#p37561
The italics don't happen in Notepad, but VS14 Maquette works spendidly
Asmus Freytag wrote,
> ...What this teaches you is that italicizing (or boldfacing)
> text is fundamentally related to picking out parts of your
> text in a different font.
Typically from the same typeface, though.
> So those screen readers got it right, except that they could
> have used
Reading & writing & 'rithmatick...
This is a math formula:
a + b = b + a
... where the estimable "mathematician" used Latin letters from ASCII as
though they were math alphanumerics variables.
This is an italicized word:
푘푎푘푖푠푡표푐푟푎푐푦
... where the "geek" hacker used Latin italics letters
Julian Bradford wrote,
* Bradfield, sorry.
Julian Bradford wrote,
"It does not work with much existing technology. Interspersing extra
codepoints into what is otherwise plain text breaks all the existing
software that has not been, and never will be updated to deal with
arbitrarily complex algorithms required to do Unicode searching.
1 - 100 of 563 matches
Mail list logo
