Jump to content

User:Revent/sandbox/Typography

From Wikipedia, the free encyclopedia

I strongly disagree with WP:MOS about many points, specifically because, TBH, a lot of WP can 'look' really bad with a 'valid' computer setup. Even changing the width of your browser window can break WP in subtle ways that most people, while they don't explicitly notice it, will subconsciously realize 'looks bad', or in ways that are glaringly obvious.

Revent/sandbox/Typography
Shortpouch Pygmy Pipehorse (A. tentaculata)
Scientific classification
Kingdom:
Phylum:
Class:
Order:
Family:
Genus:
Acentronura

Kaup, 1853

I've saved to PDF articles that looked fine on the screen but were broken in the file.

There are places where, regardless of 'local usage', MOS is wrong or incomplete, or templates are broken. This can be especially obvious in narrow infoboxes, where long data fields are a problem.

Look at edit. This is actually the wrong way to fix this, but is what I see in code, probably due to the way WP:LINEBREAK is written. It can still render incorrectly, with randomly inserted linebreaks at other locations.

edit is fixing it the correct way. Instead of forcing a possibly unneeded line break, it suppresses possible breaks and lets the renderer decide.

The Taxobox to the right is generated by this code, with a narrow image forcing the 'soft break' to show up. This will automatically render correctly, and the caption will not need 'refixing' if the photo is resized or replaced, unless it actually needs a new caption. WP:LINEBREAK doesn't describe the 'overuse' of nbsps to 'fake' a soft break, and it should, prominently.


As far as something that is literally displayed wrong everywhere, if there was a reason to put a phone number in an article, per MOS it would be 0-123-456-7890 instead of 0⁠‒​123⁠‒​456⁠‒⁠7890, which is correct. (I'm directly pasting in markup for specific glyphs, as this is AFAIK completely unsupported in wiki, which might not work for everyone. It displays correctly for me, though completely unkerned, which still looks bad. The figure dash is the same width as the numbers, and the line will not break on either side of the last one, as in US phone numbers the last 7 digits are a separate entity. You can change your window width to see it. This also affects zip codes, ISBNs, ISSNS, and other hyphenated alphanumeric strings, especially in citations. What people type, a -, is a hyphen-minus. This needs to be converted for correct display by the templates automatically.


Also, ligatures should be applied during rendering. Don't use ligatures like I'm doing here in mainspace, of course. That would be baaad. The below words are completely unsearchable, as there is XML code inside them, and might not even display right with your fontset.

oaffsh, selffsh, wolffsh, briefly, chiefly, aloofly, sniffle. These are all commonly used, but unnoticed. Look at a professionally typeset book, like an encyclopedia.
The occasional of use of soſtly and substantial is also nice looking, as long as not overdone.

This would also best be done by templates, to keep the 'intact' word in the code, and they need to be applied manually to be done right.

I have seen many good articles over time that, while the content and layout is excellent, have major typographical errors such as incorrectly placed line breaks (some composite words with ndashs should not be broken.). These are errors that are specific to the exact font used and width of the users browser window.

I want to make certain that articles I work on are 'fixed' to avoid these errors, and others that are 'user software dependent' There are possible ways to fix these things, including HTML markup or character encoding, templates, etc.

If I accidentally violate WP:MOS, which would probably by changing an stub article's 'chosen style', please tell me you care about it. If I make changes to article 'code' that cause you editing problems, like being annoyed that the article isn't using the style of quotes you like, I'm willing to 'fix' the new punctuation if you tell me.

If I do things that are 'not recommended' by WP:MOS, there is a possibility that WP:MOS is technically wrong.

For instance, English WP prefers the explicitly incorrect typewriter quotes, and the only part of the justification that isn't bogus given is that not using them is 'easier', though that is only true for some editors. Compare MOS:QUOTEMARKS with Wikipedia:Manual_of_Style/Register#Quotation_marks. Using typewriter quotes actually makes reading some sentences MUCH harder, and it removes useful 'context' for computer text analysis.
People have objected that using the correct quotes in an article title breaks searches. This is a bit silly. If you move an article with an incorrect title to the right one, you'll get an automatic redirect from the old title.

Usage of smallcaps

[edit]

The choice of the smallcaps font variant is a typographical decision, not properly a matter of writing, editing, copy-editing, or even line editing, even though on a Wiki like WP all of these jobs are the simple ‘editor’.

This is the current (May 5, 2013) beginning of NATO.

The North Atlantic Treaty Organization (NATO; /ˈnt/ NAY-toh; French: Organisation du traité de l'Atlantique Nord (OTAN)), also called the (North) Atlantic Alliance, is an intergovernmental military alliance based on the North Atlantic Treaty which was signed on 4 April 1949. The organization constitutes a system of collective defence whereby its member states agree to mutual defense in response to an attack by any external party. NATO's headquarters are in Brussels, Belgium, one of the 28 member states across North America and Europe, the newest of which, Albania and Croatia, joined in April 2009. An additional 22 countries participate in NATO's "Partnership for Peace", with 15 other countries involved in institutionalized dialogue programs. The combined military spending of all NATO members constitutes over 70% of the world's defence spending.

This is quite good copy, IMO. I’m not criticizing what people have written at all, and I had no idea how WP wanted the introduction of the acronym and translation written or ‘coded’ until I looked at this, and would require more 'intricate' things. I'm trying to improve the ‘appearance’ of the text, specifically the repeated usage of the acronym ‘NATO’ in the running text.

… by any external party. NATO’s headquarters are in …. An additional 22 countries participate in NATO’s “Partnership for Peace”, with…. The combined military spending of all NATO members constitutes…

Usage of ellipses

[edit]

… by any external party. NATO’s headquarters are in …. An additional 22 countries participate in NATO’s “Partnership for Peace”, with…. The combined military spending of all NATO members constitutes…

When using an ellipsis…

  • Punctuation never precedes the beginning of a sentence, whitespace does, so you must always use a space between an ellipsis and the beginning of a sentence.
  • You always omit preceding punctuation, unless it would change the meaning. Don’t, leave out a closing quotation mark, for instance;
  • You never omit the following punctuation if you're just omitting the tail end of a sentence or clause. The example above is the only case where you would see something such as …. …, or …? You would only use the structure ;hellip" if the end of what belongs inside the quotation marks is omitted.

This isn't intended to disagree with or join the debates about usage of quotations, etc. This is just saying that, however you do it, punctuate it correctly, please.

Style Manuals vs Typography

[edit]

A lot of use and reference is made to various style manuals in arguments on WP. This is all well and good. We definitely want correct syntax, grammar, and for citations to be in particular styles, and for particular topical areas to follow their relevant manuals.

Inappropriate use is also made, in that while the editors of WP are a ‘corporate author’, WP /itself/ is a publisher, and it is important for the encyclopedia as a whole to be as consistently and correctly typeset as possible.

As much as possible, this should be done in a way that is ‘invisible’ and unbreakable by readers and skins. As a specific example, headers should be specifically coded to always be in the 'display font' variant of whatever font family is being used.