Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
Karl, I've published similar "surveys" in the past, where the object was to get feedback on the desirability of further action. I stick by my recommendation in favor of keeping "raw data" out of the document registry and of doing the committee a favor by "adding value" in form of a sifting or "analysis" of such data. Previewing the data is not the same as making a character encoding proposal, and there aren't any procedural rules for "non-proposals", so there's nothing that prevents doing that. I have always provided some level of analysis, and I have not always chosen to register all such documents - for the reasons I gave you earlier. The original rationale for encoding certain symbols had been their widespread use. The word "widespread" is key here. At the time that Unicode was first created, symbol sets associated with printers defined widespread use. After these sets were backed into the 2600 and 2700 blocks, the phenomenal rise of Windows made the W/W-Dings sets even more widespread. As you and WG2 evaluate additional such widely disseminated fonts, you will need to come up with your own criteria of what constitutes "widespread". Those criteria should be applied both to the fonts considered as potential source of symbols, as well as to each category of symbols within these fonts. I'll be interested in looking at a list of Apple symbols, once it's categorized a bit better by symbol function and / or gives a better idea of which (and how many) symbols extend existing sets (e.g. by adding directional variants) and which (and how many) might possibly be only variants of existing symbols - and similar information like that. (Unlike a full character encoding proposal I would not expect definite answers to these, but some tentative / approximate information would be nice). A./
Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
On 7/16/2011 1:53 AM, Michael Everson wrote: On 16 Jul 2011, at 04:37, Asmus Freytag wrote: It's not a matter of competing "views". There's a well-defined process for adding characters to the standard. It starts by documenting usage. Yes, Asmus, and when one wants to do that, one writes a proposal. We aren't writing a proposal here. We're *talking* about things. I fully understand the difference between making a formal proposal (that can be acted upon) and informally chatting about the possible needs for some characters - and the chances that a successful proposal might be written. However, if the only hard information are assertions of personal preference such as "Sometimes I might want to show a dotted box for NBSP and sometimes a real NBSP", it is a bit much to then conclude "What I see is a certain unreasonability reflecting a certain conservatism" because there isn't an immediate, public enthusiasm for the idea. A./ PS: My counter-assertion, that much of the technical literature uses the abbreviations in preference to dashed boxes, has been pointedly ignored by you. UAX#9, bidi, and UAX#14, linebreak, extensively discuss invisible characters - neither of these documents needs symbol characters, in fact, they would probably reduce clarity. This practice goes back over 15 years, so it can be seen as "settled". (I further assert that I expect examples could be found outside the standard as well). PPS: If anybody provides evidence (suitably "documented" for the level of discussion) of widespread use of symbolic depictions for certain invisible characters, I'd be quite open to review it and to base my future position on this new basis.
Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
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
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
(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" :
>
>
> 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.
>
>
Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
Am Freitag, 15. Juli 2011 um 19:48 schrieb Asmus Freytag: AF> The document registry should be limited to documents that can and should AF> be reviewed in committee. WG2 N4127 is, by its content and the reference in its introduction, an appendix to the German NB requests expressed in WG2 N4085. It provides detailed information which had been included in WG2 N4085 itself if anybody had the time to prepare this in time before the Helsinki meeting. As such, it is placed there where WG2 N4085 is. Also, it can be reviewed. However, as it is not a character encoding proposal, the items to be reviewed are not the single characters. The question addressed by the time of writing WG2 N4085 is: "Is it appropriate to encode characters based on the widespreadness of a speific set of fonts only - and if yes, which fonts are to be included?" In the meantime, the first part of this question was answered in Helsinki with "Yes". This reduces the German NB request in WG2 N4085 that other manufacturers have to be treated equal like Microsoft. To see what this request really means, it is convenient what such fonts of other OS manufacturers really contain. To show this for one of them (Apple in this case), is the *ONLY* intent of WG2 N4127. To work on a character proposal, the main question has to be answered first (and this question is the only thing subject to a formal review at this time) is: Shall the Apple symbols be encoded on the same base as the Wingding/Webding symbols, i.e. based on the widespreadness of the font only? Of course, such a decision has take into account any statement from Apple themselves, and should not me made before such is there. Also, before such a decision is taken, it is not appropriate to start any work on an encoding proposal. (If someone finds specimens in the list for other proposals which go the usual way, taking their evidence from plain text use elsewhere [like e.g. chart symbols], this is completely independent.) As John Jenkins correctly pointed out, it is too early for a character encoding proposal. Thus, I did *deliberately* not start any work which is appropriate for a character proposal, starting with sorting out the already encoded characters or the not encodable logos. Also, it seems that I have to emphasize that I did not intend to start a new encoding project. The subject of my mail deliberately states "(in context of the Wingding/Webding proposal)". - Karl
Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
On 16 Jul 2011, at 04:37, Asmus Freytag wrote: > It's not a matter of competing "views". There's a well-defined process for > adding characters to the standard. It starts by documenting usage. Yes, Asmus, and when one wants to do that, one writes a proposal. We aren't writing a proposal here. We're *talking* about things. > If you can document such usage, and if it is widespread, and settled enough > to warrant standardization to support it, then a proposal based on such > documentation is something that should be reviewed according to the > established process. > > I don't really need to tell you this, as you are quite familiar with how the > process works. No, you really don't. :-/ Michael Everson * http://www.evertype.com/
Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
On 16 Jul 2011, at 09:08, Julian Bradfield wrote: >> The other two could be proposed as unitary symbols, if anybody really needs >> to represent them. They are commensurate with a large number of similar >> symbols consisting of various numbers of horizontal lines crossed by various >> numbers of vertical lines. See, e.g., 29FA, 29FB, 2A68, 2A69, 2AF2, 2AF5. > > They could, but wouldn't the same principle that bans new precomposed > accented characters applies? If not, why not? I think the ban would apply only if it were suggested that there be a canonical decomposition for the characters encoded. Michael Everson * http://www.evertype.com/
Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)
>The record mark (IBM GCGID SS95) consists of two horizontal lines >crossed >by one vertical line. > >The segment mark (IBM GCGID SS96) consists of three vertical lines >crossed >by one horizontal line. > >The group mark (IBM GCGID SS97) consists of three horizontal lines >crossed >by one vertical line. Ah, thanks - my fault, it didn't occur to me that I should look between R and S to find a record mark, instead of at the beginning with the other weird stuff! What a system... >The other two could be proposed as unitary symbols, if anybody really >needs to >represent them. They are commensurate with a large number of similar symbols >consisting of various numbers of horizontal lines crossed by various numbers >of vertical lines. See, e.g., 29FA, 29FB, 2A68, 2A69, 2AF2, 2AF5. They could, but wouldn't the same principle that bans new precomposed accented characters applies? If not, why not? -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
