Minor layout issue

[Robert Urmann]

Dear Admins,

I noticed that when using

Code: Select all

{{editions|xy}}

the phrase is set in italics while the brackets are set upright. This leads to collisions of brackets and content in many cases.

Is this worth to be fixed?

Robert

[Robert Urmann]

Dear Admins again,

seems that my suggestion isn't worth to be fixed

Anyway, to me it looks more equal to have (3 editions available) rendered rather than (3 editions available). Another possibility would be to set it all in normal text: (3 editions available).

This is not the only implementation issue; it's also on the main page, where italic numbers collide with upright braces, e.g. Texts (7626).

I know that I could type

Code: Select all

''(3 editions available)''

to bypass it, but I thought that the use CPDL templates is the preferred way.

Thank you all for a short reply!

Robert

[carlos]

Hi Robert, sorry for not replying to you before, I hadn't seen your first message above.

Minor as it may seem, in fact this issue has found no agreement even between the admins. I personally favor the italicized parentheses suggested by you, but Chuck seems to prefer them without the italics. The site has been using this for a long time now, and you know, old habits are hard to change... Perhaps if other users join in and start giving their opinions, we could reach a consensus on this subject.

Best regards,
Carlos

[carlos]

Hi again Robert, I just had a look at the Wikipedia article for Italic type and found this suggestion:

The Chicago Manual of Style suggests that to avoid problems such as overlapping and unequally spaced characters, parentheses and brackets surrounding text that begins and ends in italic or oblique type should also be italicized (as in this example). An exception to this rule applies when only one end of the parenthetical is italicized (in which case roman type is preferred, as on the right of this example).

But in this other site, the recommendation is just the opposite:

In Bringhurst’s Elements he directs us to use upright parentheses, brackets, and braces even if the context is italic.

I'm starting to think that this is more a matter of personal taste than enything else.

[vaarky]

Apologies--I missed this on its first go-around too. That doesn't mean I'm not opinionated on the subject.

I used Bringhurst when working for a design publication; I used a designated big honking typesetting machine (I still miss that solvent smell!). In fact, part of my job was to look for and fix things like what is being described here (different digits require different amounts of padding, plus it varies based on the individual typeface). I used the AP Stylebook when working for newspapers and other publications aimed at contexts that have limited typesetting and are read quickly for content rather than savored for the art of design. I also have a fondness for the journalism stylebook approach. Different tools for different contexts.

Fond as I am of Bringhurst, CPDL should generally follow a journalism stylebook such as Chicago over Bringhurst. If we operated in an environment where we had the luxury of having a typographer adjust the spacing between the specific numeric digit and the closing parenthesis, then by all means we should follow Bringhurst. On CPDL, however, it is not scalable or desirable for us to make this type of microadjustment. Furthermore, the reality is that the content is being rendered by various browsers, some of which choose to trump the font for preference reasons, and some trump the font for disability reasons.

The goal of CPDL is to make the information readable at first glance for the most (ideally all) people. Therefore, we need a solution for parens that works generally without collisions. The proper solution in light of CPDL's environment is to keep the italicization consistent to avoid collisions when a user's browser renders the information. The best way to avoid collisions is to keep the italicization consistent between the parens and the text they bracket: either all italicized, or all not italicized. If parens have to be placed inside a non-italiicized sentence, it's more important for the parens to match their inside content and not collide with inside content (which could contain text) than for the ending parenthesis to avoid colliding with the punctuation following it if that's what follows it rather than a space.

I'd be interested in hearing other views.

[Robert Urmann]

Thank you all for taking care of this!

Of course I am aware of the screen rendering problem and fewer means for good "typesetting" due to HTML and CSS restrictions! Not to forget browser-specific behaviour and support for special characters such as thinspaces.
To my basic knowledge punctuation should follow the shape of the text; e.g. commas after italic text are italicized as well as exclamation marks or question marks. This should also be applied to parens.

On CPDL italic text is in extensive use – often it loses its emphasizing effect; I mean, all links to work pages are markuped twice: as a hyperref AND italicized. Btw, parens enclosing icons are set upright! So why shouldn't they in the available editions context? My current solution for using normal and italic text moderately is the one on the Brahms page: Entries in normal type list complete works or compilations. Entries in italics mark parts, extracts, or incomplete settings of a larger work.

My suggestion is to set the "available editions" output in normal text and parens. Probably this is most close to the parenthesized icon practice. Concerning the collision avoidance it would be fine to have parens and text upright (italicized parens are not that nice, at least to me).

Well, that is my opinion. Let's see what others think.

Yours,
Robert

[CHGiffen]

My experience goes back to before Bringhurst, with whom I agree, and to the development of Donald Knuth's computerized typesetting and fontmaking systems TeX and MetaFont (as well as spinoffs such as LaTeX, and my own aborted musical typesetting program based on TeX, which I called TaLLiS). Knuth and many many others before him were acutely aware of the subtleties of kerning, ligatures, etc.

For the time being, I've inserted a hairspace before the right parentheses in both Template:Editions, and in the CPDL statistics section of the Main Page, using Template:spc. I also made a page accessible from my user page that deals with spacing.

Chuck

[Robert Urmann]

Chuck: this is incredible! Thank you so much for this "cosmetic surgery". I think that's an overall satisfying solution. I'm sure that others, too, will realize such detailed corrections; at least those who appreciate LaTeX's microtype package

All best wishes,
Robert

[CHGiffen]

Thanks to you, too, Robert! It suddenly occurred to me that there are encodings for spaces of various widths, just when I was thinking about my old TeX interests. So it was a relatively easy matter to check them out and implement a spacing template and make the requisite insertions.

TeX and LaTeX are so much better at handling these things invisibly to the user, which really puts the various popular word processing and browser implementations to shame. I almost never use Word to write documents, preferring instead to use LaTeX if I'm at all worried about the final appearance. I guess that also stems, at least in part, from having been a professional mathematician for four decades, where TeX, LaTeX, AMSTeX, etc. represent the standard of excellence.

Anyway, now we have the means to "tweak" our display spacing! Too bad that we don't have a negative thin- or hair-space, though.

Chuck

[carlos]

Hey Chuck, the idea was good, but I'm sorry to say that it didn't work out for me in neither browsers. In Firefox (v2.20), what should have been a hairspace is displaying as a large space. And in IE (v6.0) it simply displays a box in the place of the space, an indication that it depends on the user having a proper font file installed so as to be correctly displayed.

CPDL-Firefox-italics.png (19.16 KiB) Viewed 14039 times

CPDL-IE-italics.png (17.98 KiB) Viewed 14039 times

Perhaps you can try to fix the Spc template using style="text-width: 1px" or something in this fashion, so as to end up with a solution that is completely browser- and system-independent. If this is not viable, then the only alternative I see is to completely abandon the italics in these cases, as Robert suggested above.

[CHGiffen]

Thanks Carlos. I've disabled the template:spc until we can figure out a workaround. I took the spacing for hairwidth (and other widths) from Palatino Linotype (my default font, which I use in all my Finale work). I'm gone for the weekend, but will work on it as soon as I return.

Chuck

[carlos]

Hi Chuck, the style sheet method worked well and generated a hairspace with the following setting:

Code: Select all

<span style="word-spacing:-3px;"> </span>

This method is displaying fine in both my browsers, please check in yours too.

Unfortunately though, I couldn't manage to make it work from inside the template, I can't figure out what's happening. Perhaps you can find it out later, when you return.

[CHGiffen]

Thanks, Carlos. I fiddled with variants of your idea within the Template:spc. Finally, after some snooping, I came across " " which is the HTML code for a thinspace (= 2 hairspaces = 1/6 em). I've changed the template so that now {{spc|n}} puts in "n" thinspaces (n=0,1,...6), defaulting to a single thinspace. Unfortunately, there is no HTML entity for hairspace, but the thinspace solution seems to work alright for Template:Editions.

Chuck

[carlos]

Bad news:   is also not rendered correctly by Internet Explorer v6.0, which displays it as a wide space (or little squares, when the Spc template is used with a parameter)

[CHGiffen]

Hmmmm. I have IE 8. That must be the problem, because it works just fine for me, and these HTML entities are supposed to be recognized. Maybe IE 6 is just too old and needs to be upgraded?

Anyway, I'll disable the template:spc again.

Chuck