Vincent,
Vincent Hennebert schrieb:
However, on this particular change I still don’t agree. Replacing hyphen
with minus and vice-versa is likely to give an ugly result. Why not adding
en dash and em dash while we’re at it? I’d rather add hyphentwo (U+2010)
to the list of alternatives for
Hi All,
Thanks for your comments.
Jeremias Maerki wrote:
On 03.12.2008 11:48:40 Vincent Hennebert wrote:
snip/
Plus, while it makes sense to replace
minus-sign with hyphen-minus when minus-sign is not available, the other
way around is not acceptable. Anyway, since in practice this will
Jeremias Maerki wrote:
On 02.12.2008 18:40:21 Vincent Hennebert wrote:
snip/
(example: with {zero, zerooldstyle} zero is added as a fall-back for
zerooldstyle and vice-versa). I’m not sure this is very useful anyway:
the usage of the method shows that the first glyph is a ‘common’ one,
likely
On 03.12.2008 11:48:40 Vincent Hennebert wrote:
snip/
Plus, while it makes sense to replace
minus-sign with hyphen-minus when minus-sign is not available, the other
way around is not acceptable. Anyway, since in practice this will
probably never happen, the whole thing can probably be
Jeremias Maerki wrote:
On 02.12.2008 18:40:21 Vincent Hennebert wrote:
FWIW, I am happy with the glyph substitution the way Jeremias has
implemented it.
Hi Jeremias,
Jeremias Maerki wrote:
Plus, while it makes sense to replace
minus-sign with hyphen-minus when minus-sign is not
Quoting Jeremias Maerki [EMAIL PROTECTED]:
No, but that could easily be included in AbstractCodePointMapping where
the substitution is controlled from. That would be easier to implement
than an event in the event processing framework as
AbstractCodePointMapping doesn't have access to the user
Hi Vincent,
these alternatives are only taken as a last resort before mentioning
that a glyph cannot be found. Unicode does list minus (Unicode: 2212,
MINUS-SIGN) to be related to hyphen (Unicode: 002D, HYPHEN-MINUS).
Otherwise, I wouldn't have made the change. The change is also not about
Jeremias Maerki wrote:
On 02.12.2008 13:51:06 Chris Bowditch wrote:
snip/
I think making the whole SVG Text process more transparent would
really help as it seems quite mystical. I know you made some further
notes on this process yesterday, but some more details about Font
substitution
On 02.12.2008 14:50:12 Chris Bowditch wrote:
Jeremias Maerki wrote:
On 02.12.2008 13:51:06 Chris Bowditch wrote:
snip/
I think making the whole SVG Text process more transparent would
really help as it seems quite mystical. I know you made some further
notes on this process
Quoting Jeremias Maerki [EMAIL PROTECTED]:
Hi Vincent,
these alternatives are only taken as a last resort before mentioning
that a glyph cannot be found. Unicode does list minus (Unicode: 2212,
MINUS-SIGN) to be related to hyphen (Unicode: 002D, HYPHEN-MINUS).
Otherwise, I wouldn't have made
No, but that could easily be included in AbstractCodePointMapping where
the substitution is controlled from. That would be easier to implement
than an event in the event processing framework as
AbstractCodePointMapping doesn't have access to the user agent. If we
decide to make it an event (which
Hi Jeremias,
Jeremias Maerki wrote:
Hi Vincent,
these alternatives are only taken as a last resort before mentioning
that a glyph cannot be found. Unicode does list minus (Unicode: 2212,
MINUS-SIGN) to be related to hyphen (Unicode: 002D, HYPHEN-MINUS).
Otherwise, I wouldn't have made the
On 02.12.2008 18:40:21 Vincent Hennebert wrote:
Hi Jeremias,
Jeremias Maerki wrote:
Hi Vincent,
these alternatives are only taken as a last resort before mentioning
that a glyph cannot be found. Unicode does list minus (Unicode: 2212,
MINUS-SIGN) to be related to hyphen (Unicode:
13 matches
Mail list logo
