Chicago/MLA ellipsis versus the Unicode defined AP ellipsis

[Asmus Freytag]

There are two arguments that would prevent either a new code point or a 
variation sequence from being a complete solution.

One is the case of monospaced fonts, were most likely neither would 
result in something that's wider than a standard cell. (Although some 
people design fonts that are only "mostly" monospaced).

While we are at the monospaced fonts, they don't work well with inserted 
spaces, as the gaps are already present. In fact it's clear that the 
CoMS is fairly wedded to ensuring that you get the same effect as typing 
three dots on a typewriter...

Typewriters and monospaced fonts would get the desired effect 
automatically also for adjacent punctuation.

It is only when dealing with variable width fonts that one would need to 
manually add spaces in order to achieve the typewritten appearance.

It would seem in this light, that our discussion of Ellipsis  (p. 277 in 
15.0) is incomplete.

Because, following your argument, we would argue that the encoding of an 
ellipsis as a sequence of alternating U+002E with NBSP or NNBSP is 
something we recommend (based on the desired spacing) even when, 
semantically, the sequence is fully an equivalent of what is otherwise 
encoded by the ellipsis.

I would suggest changing the following sentence to better map out the 
conventions.

"For example, in a monowidth font, a sequence of threefull stopswill be 
wider
than thehorizontal ellipsis, but in a typical proportional font, afull 
stopis very narrow and
a sequence of three of them will be more tightly spaced than the dots 
inhorizontal ellipsis."

<break para>

In a monowidth font, a sequence of three/full stops/will be wider
than /horizontal ellipsis/, and may be the appropriate when following style
guides that require more widely spaced dots. In this case, the spacing 
between the
last dot and following punctuation would be as expected.

In contrast, for typical proportional font, a/full stop/is very narrow and
a sequence of three of them will be more tightly spaced than the dots 
in/horizontal ellipsis/.
When following style guided calling for more widely spaced dots, established
practice calls for separating the dots (and any surrounding punctuation) by
either a NBSP or NNBSP.

<continue with the para starting with "Conventions", although I would 
prefer calling them "Notational conventions" to distinguish them even 
more from conventions expressed in presentational style guides>

A./


On 4/17/2023 3:37 PM, Ken Whistler via Unicode wrote:
> Asmus,
>
> I'm gonna disagree. Adding a variation sequence would just confuse 
> existing practice, and wouldn't deal with the edge cases where the 
> spaced-out ellipses bump into other punctuation. See a more nuanced 
> discussion of the issue at:
>
> https://cmosshoptalk.com/2019/07/30/dot-dot-dot-a-closer-look-at-the-ellipsis/ 
>
>
> Basically, an ellipsis is an ellipsis is an ellipsis, sure, but when 
> one gets to concerns about exact appearance in a publication, that 
> becomes a copyedit issue, and standard practice is simply to insert 
> the NBSP (or NNBSP, depending on preference) to space dots out to 
> match the spec and prevent unwanted line breaks. It may be a bit of a 
> PITA for somebody who uses ellipses in text to have to insert NBSP in 
> some instances to follow the style guide, but as a copyedit issue, 
> that basically falls into the same category, in my reckoning, as 
> worrying about whether the periods are inside or outside of the 
> quotation marks, for example.
>
> One should not assume that plain text poured into a text renderer is 
> automatically going to follow every last detail of a style guide such 
> as CMOS. Preparation for publication assumes markup for styling, of 
> course, but may also require specialized handling for hyphenation (or 
> prevention thereof) *and* attention to detail of spacing that might 
> not be entirely handled automatically by a generic renderer.
>
> So I'm not in favor of getting variation selectors involved here as 
> well, which would likely just introduce more distinctions that 
> wouldn't always work as expected but would likely require more hacky 
> overrides in edge cases if used.
>
> --Ken
>
> On 4/17/2023 1:56 PM, Asmus Freytag via Unicode wrote:
>> Given the facts as stated, the conclusion would be that this should 
>> be proposed for a variation sequence.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230417/249cab90/attachment.htm>