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 Mon, Jan 28, 2019 at 2:31 AM Mark Davis ☕️ wrote:
> But the question is how important those are in daily life. I'm not sure
> why the double-click selection behavior is so much more of a problem for
> Ancient Greek users than it is for the somewhat larger community of English
> users. Word
Note that this is no different than the reasonably common cases in English
such as «the boys’ books».
(you can try various combinations in
http://unicode.org/cldr/utility/list-unicodeset.jsp)
There are certainly cases that are suboptimal in word selection. As another
example, «re-iterate» seems
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 was the
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
Apart from that control sequences for (some) styling is standardised
(since decades by now), and the "tag characters" approach is not:
For the control sequences for styling, there is no pretence of nesting,
just setting/unsetting an aspect of styling. For etc. (in tag
characters) there is at
You're not very explicit about the Tag encoding you use for these styles.
Of course it must not be a language tag so the introducer is not U+E0001,
or a cancel-all tag so it is not prefixed by U+E007F
It cannot also use letter-like, digit-like and hyphen-like tag characters
for its introduction.
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 was the solution but no one here
> > has agreed so far.
> If there
On Sun, 27 Jan 2019 14:09:31 -0500
James Tauber via Unicode wrote:
> On Sun, Jan 27, 2019 at 1:22 PM Richard Wordingham via Unicode <
> unicode@unicode.org> wrote:
> > However LibreOffice treats "don't" as a single word for U+0027,
> > U+02BC and U+2019, but "dogs'" as a single word only for
For Volapük, it looks much more like U+02BE (right half ring modifier
letter)
than like U+02BC (apostrophe "modifier" letter).
according to the PDF on
https://archive.org/details/cu31924027111453/page/n12
The half ring makes a clear distinction with the regular apostrophe (for
elisions) or
On 2019-01-27, Michael Everson via Unicode wrote:
> On 27 Jan 2019, at 05:21, Richard Wordingham
> wrote:
>> The closing single inverted comma has a different origin to the apostrophe.
> No, it doesn’t, but you are welcome to try to prove your assertion.
As far as I can tell from the easily
> On Jan 27, 2019, at 12:09 PM, James Tauber via Unicode
> wrote:
>
> γένοιτ’ ἄν
>
> Double-clicking on the first word should select the U+2019 as well.
> Interestingly on macOS Mojave it does in Pages[1] but not in Notes
On my ipad/iphone, Word does it correctly but Pages and Notes do
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 Sun, Jan 27, 2019 at 1:22 PM Richard Wordingham via Unicode <
unicode@unicode.org> wrote:
> Except the Uniocde-compliant processes aren't required to follow the
> scheme of TR27 Unicode Text Segmentation. However, it is only required
> to select the whole word because the U+2019 is followed
On Sun, 27 Jan 2019 16:11:12 +
Michael Everson via Unicode wrote:
> Yes, yes. It doesn’t matter. The discussion applies to both the two
> quotation marks and the two modifier letters.
Actually, there is a difference. As the ʻokina doesnʹt occur at the
end of a word in Hawaiian, one only
On Sun, 27 Jan 2019 12:38:39 -0500
"Mark E. Shoulson via Unicode" wrote:
> On 1/27/19 11:08 AM, Michael Everson via Unicode wrote:
> > It is a letter. In “can’t” the apostrophe isn’t a letter. It’s a
> > mark of elision. I can double-click on the three words in this
> > paragraph which have the
On 1/27/19 11:08 AM, Michael Everson via Unicode wrote:
It is a letter. In “can’t” the apostrophe isn’t a letter. It’s a mark of
elision. I can double-click on the three words in this paragraph which have
the apostrophe in them, and they are all whole-word selected.
That doesn't work when I
Well, sure; some languages work better with some fonts. There's nothing
wrong with saying that 02BC might look the same as 2019... but it's
nice, when writing Hawaiian (or Klingon for that matter) to use a bigger
glyph. That's why they pay typesetters the big bucks (you wish): to make
things
Yes, yes. It doesn’t matter. The discussion applies to both the two quotation
marks and the two modifier letters.
> On 27 Jan 2019, at 15:08, Tom Gewecke via Unicode wrote:
>
>
>> On Jan 26, 2019, at 11:08 PM, Richard Wordingham via Unicode
>> wrote:
>>
>> It may be a matter of literacy in
On 27 Jan 2019, at 05:21, Richard Wordingham
wrote:
>>> 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.
>>
>>
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)
> On Jan 26, 2019, at 11:08 PM, Richard Wordingham via Unicode
> wrote:
>
> It may be a matter of literacy in Hawaiian. If the test readership
> doesn't use ʼokina,
I think the Unicode Hawaiian ʻokina is supposed to be U+02BB (instead of
U+02BC).
On Sunday, 27 January 2019, Asmus Freytag via Unicode
wrote:
>
> Choice of quotation marks is language-based and for novels, many times
> there are
> additional conventions that may differ by publisher.
>
> Wonder why the publisher is forcing single quotes on them
>
In theory quotation marks
24 matches
Mail list logo
