Why could'nt we have "dotted square brackets" encoded, allowing then
fonts to contain ligatures to generate the symbols, possibly with help
of ligature hinting (using joiner controls), to enclose the characters
in-between ?
E.g. "[RLO]", where the "[", "]" would be the encoded dotted square
brackets. The full sequence could be hinted to generate the ligature
as
<ENCLOSING OPEN DOTTED SQUARE BRACKET, ZWJ, LATIN CAPITAL LETTER R,
ZWJ, LATIN CAPITAL LETTER L, ZWJ, LATIN CAPITAL LETTER O, ZWJ,
ENCLOSING CLOSE DOTTED SQUARE BRACKET>
No need then to encode all controls as pairs. Fonts can still be
produced that will recognize and display the ligatures to generate the
necessary "pictures", from regular character.
There are other similar features, for simple enclosures : in
[rectangles], /triangles\ or \triangles/ or <triangles] or [triangles>
(circles/ovals), [|key|], {hexagons} or <=hexagons=>... (here I just
used ASCII art to approximate them); with simple or double or thick
enclosures... Example of use for creating "cartouches".
Even if the fonts are not recognizing these ligatures themselves, a
text renderer may still automatically generate them using text
decoration of the bracketed text encoded within, or using the enclosed
character already encoded in the UCS.
And there are possible display fallbacks: a font for example can still
map these characters are symbols, overriding outside their left or
right side bearings, so that, when rendered with nothing between them,
their strokes will overstrike natively to make the enclosure (as these
characters would be joining).
No need to specify specific metrics (it should not matter here if they
display a true square area or a recangular area). Ligatures may still
be produced by the renderer or in the font itself, to make the
enclosed text (e.g. up to 4 characters) fit within it automatically,
if trying to avoid too long rectangular areas or trying to fit a
square.
They should not be encoded as "format characters", but as punctuation
marks, similar to brackets and parentheses, with mirroring supported
for RTL scripts, to allow these reasonnable display fallbacks
explicitly.
-- Philippe.
2011/7/15 "Martin J. Dürst" <duerst_at_it.aoyama.ac.jp>:
>
>
> On 2011/07/15 18:51, Michael Everson wrote:
>>
>> On 15 Jul 2011, at 09:47, Andrew West wrote:
>
>>> If you want a font to display a visible glyph for a format or space
>>> character then you should just map the glyph to its character in the font,
>>> as many fonts already do for certain format characters.
>>
>> Sometimes I might want to show a dotted box for NBSP and sometimes a real
>> NBSP. Or many other characters. Or show a RTL and LTR override character
>> without actually overriding the text. You'd need a picture for that, because
>> just putting in a glyph for it would also override the text.
>
> I understand the need. But then what happens is that we need a picture in
> the standard for "the character that depicts an RLO (but isn't actually
> one)". And then you need another character to show that picture, and so on
> ad infinitum. This doesn't scale.
>
> If we take the needs of charaacter encoding experts when they write *about*
> characters to decide what to make a character, then we get many too many
> characters encoded. That's similar to the need of typographers when they
> talk about different character shapes. If we had encoded a Roman 'a' and an
> Italic 'a' separately just because the distinction shows up explicitly in
> some texts on typography, that would have been a mistake (the separation is
> now available for IPA, but that's a separate issue).
>
> Regards, Martin.
>
>
Received on Sat Jul 16 2011 - 04:46:59 CDT
This archive was generated by hypermail 2.2.0 : Sat Jul 16 2011 - 04:47:00 CDT