On Wed, Jul 28, 2010 at 11:37:28AM -0700, Asmus Freytag wrote:
On 7/28/2010 10:09 AM, Murray Sargent wrote:
Contextual rendering is getting to be more common thanks to
adoption of OpenType features. For example, both MS Publisher 2010
and MS Word 2010 support various contextually dependent
Den 2010-07-29 08.47, skrev Khaled Hosny khaledho...@eglug.org:
I have few fonts where I implemented a 'locl' OpenType feature that maps
European to Arabic digits, and contextual substitution feature that
replaces the dot with Arabic decimal separator when it comes between two
Arabic
2010/7/28 Asmus Freytag asm...@ix.netcom.com
On 7/28/2010 9:30 AM, André Szabolcs Szelp wrote:
You really all say, that general property Sk (DOT ABOVE) rather than Po
(FULL STOP, COMMA, MIDDLE DOT) (compared with all other decimal point
characters) can not cause any problems ever in certain
On Thu, Jul 29, 2010 at 10:01:37AM +0200, Kent Karlsson wrote:
Den 2010-07-29 08.47, skrev Khaled Hosny khaledho...@eglug.org:
I have few fonts where I implemented a 'locl' OpenType feature that maps
European to Arabic digits, and contextual substitution feature that
replaces the dot
On Thu, Jul 29, 2010 at 10:15, Khaled Hosny khaledho...@eglug.org wrote:
Also, I don't buy in Unicode idea of
encoding different sets of decimal digits separately, they are all
different graphical presentations of the same thing.
Not in a document where the author is discussing the
On 2010/07/29 19:51, Juanma Barranquero wrote:
On Thu, Jul 29, 2010 at 10:15, Khaled Hosnykhaledho...@eglug.org wrote:
Also, I don't buy in Unicode idea of
encoding different sets of decimal digits separately, they are all
different graphical presentations of the same thing.
Not in a
On Fri, Jul 30, 2010 at 04:52, Martin J. Dürst due...@it.aoyama.ac.jp wrote:
It's very clear that we would get nowhere if we wanted to encode
all these.
The comment I respondend to talked about characters that are already encoded.
In simpler words, you cannot use the needs of discussions
Hello Joanma,
On 2010/07/30 12:05, Juanma Barranquero wrote:
On Fri, Jul 30, 2010 at 04:52, Martin J. Dürstdue...@it.aoyama.ac.jp wrote:
It's very clear that we would get nowhere if we wanted to encode
all these.
The comment I respondend to talked about characters that are already encoded.
Dear Colleagues,
In processing a document, I came across a punctuation character which
I was not able to find in Unicode. As I find it hard to believe that
the character has not been encoded yet, I must think my search was
incomplete, and I'd be hoping that you can point me to the correct
André Szabolcs Szelp wrote:
Generally, for the decimal point . (U+002E FULLSTOP) and , (U+002C
COMMA) is used in the SI world. However, earlier conventions could use
different notation, such as the common British raised dot which
centers with the lining digits (i.e. that would be U+00B7 MIDDLE
Den 2010-07-28 09.50, skrev Jukka K. Korpela jkorp...@cs.tut.fi:
André Szabolcs Szelp wrote:
Generally, for the decimal point . (U+002E FULLSTOP) and , (U+002C
COMMA) is used in the SI world. However, earlier conventions could use
different notation, such as the common British raised dot
Kent Karlsson wrote:
And the Nameslist says:
002EFULL STOP
= period, dot, decimal point
* may be rendered as a raised decimal point in old style numbers
Right, I remembered there is such a comment somewhere but did not remember
where.
However, I think that is a bad idea: firstly
On 7/28/2010 2:02 AM, Kent Karlsson wrote:
Den 2010-07-28 09.50, skrev Jukka K. Korpela jkorp...@cs.tut.fi:
André Szabolcs Szelp wrote:
Generally, for the decimal point . (U+002E FULLSTOP) and , (U+002C
COMMA) is used in the SI world. However, earlier conventions could use
different
Den 2010-07-28 17.09, skrev Jukka K. Korpela jkorp...@cs.tut.fi:
Kent Karlsson wrote:
And the Nameslist says:
002EFULL STOP
= period, dot, decimal point
* may be rendered as a raised decimal point in old style numbers
Right, I remembered there is such a comment somewhere but
You really all say, that general property Sk (DOT ABOVE) rather than Po
(FULL STOP, COMMA, MIDDLE DOT) (compared with all other decimal point
characters) can not cause any problems ever in certain algorithms?
Szabolcs
Contextual rendering is getting to be more common thanks to adoption of
OpenType features. For example, both MS Publisher 2010 and MS Word 2010 support
various contextually dependent OpenType features at the user's discretion. The
choice of glyph for U+002E could be chosen according to an
On 28 Jul 2010, at 18:09, Murray Sargent wrote:
Contextual rendering is getting to be more common thanks to adoption of
OpenType features. For example, both MS Publisher 2010 and MS Word 2010
support various contextually dependent OpenType features at the user's
discretion. The choice of
On 7/28/2010 10:09 AM, Murray Sargent wrote:
Contextual rendering is getting to be more common thanks to adoption of OpenType features. For example, both MS Publisher 2010 and MS Word 2010 support various contextually dependent OpenType features at the user's discretion. The choice of glyph for
Asmus asks, Which implementation makes the required context analysis to
determine whether 002E is part of a number during layout? If it does make this
determination, which OpenType feature does it invoke? Which font supports this
particular OpenType feature?
I haven't looked to see if our
Michael asks, Are or will be OT features supported in, say, filenames? The
answer depends on the renderer. For example, if you display filenames in
NotePad using the Calibri font, default English ligatures are used
automatically using OpenType table info.
Murray
On 28 Jul 2010, at 21:25, Murray Sargent wrote:
Michael asks, Are or will be OT features supported in, say, filenames? The
answer depends on the renderer. For example, if you display filenames in
NotePad using the Calibri font, default English ligatures are used
automatically using
Michael asks, Are or will be OT features supported in, say, filenames? The
answer depends on the
renderer. For example, if you display filenames in NotePad using the Calibri
font, default English
ligatures are used automatically using OpenType table info.
I meant on the desktop or in the
On 28 July 2010 18:41, Michael Everson ever...@evertype.com wrote:
Contextual rendering is getting to be more common thanks to adoption of
OpenType features. For example, both MS Publisher 2010 and MS Word 2010
support various contextually dependent OpenType features at the user's
Murray Sargent murrays at exchange dot microsoft dot com wrote:
It's worth remembering that plain text is a format that was introduced
due to the limitations of early computers. Books have always been
rendered with at least some degree of rich text. And due to the
complexity of Unicode, even
Doug comments:
Murray Sargent murrays at exchange dot microsoft dot com wrote:
It's worth remembering that plain text is a format that was introduced
due to the limitations of early computers. Books have always been
rendered with at least some degree of rich text. And due to the
25 matches
Mail list logo
