‘Le siècle des Lumières [plural] … Le terme de «Lumières» a été consacré par l’usage pour rassembler la diversité des manifestations de cet ensemble d’objets [la superstition, l’intolérance, l’abus des Églises et des États].’ (fr.wikipedia.org) — Except for Postmodernism, an era does not usually give itself a name. The term was coined later on (say, just about the acme of the revolution’s Terror, when a cult of such lights/gleams/luminaries was contrived). Where in German it reads ‘Aufklärung’, in French ‘éclaircissement’ is used instead.
First words of the Bible: בְּרֵאשִׁית, בָּרָא אֱלֹהִים, אֵת הַשָּׁמַיִם, וְאֵת הָאָרֶץ. ‘In the beginning God created the heaven and the earth.’ (Gn 1,1) — Okay, the third verse reads, in French (Bible de Sacy translation): ‘Or Dieu dit: Que la lumière soit faite. Et la lumière fut faite.’ — Not a plural.
The angel of the light = Lucifer (<Lat. ‘light-bearer’); cfr 2 Cor. 11:14: ‘And no wonder, for Satan himself masquerades as an angel of light.’ — I don’t believe Kant could ever have imagined him being associated with satanism…
Punctuation is a challenge. To electronically type-write modern Ethiopic languages (like Amharic) in Ge’ez script the regular (Western) word space (U+0020) is used as a word boundary. Properly typesetting classical Ge’ez however requires usage of the colon-like Ethiopic Wordspace (፡ U+1361). But how to do so and implement text encoding is unsure.
First, I simply substituted all word spaces (and equivalent white space characters) with U+1361. Obviously this breaks things. For one, each and every text editor (unaware as they are of ፡’s existence as an alternative word divider character) treats the incoming bitstream as a very long string in which there is not a single word boundary, and thus no opportunity to break lines. Combined with the fact that there do not exist hyphenation pattern dictionaries for classical Ge’ez, text encoded like this can basically not even be rendered on screen, unless as a single, indefinitely overflowing line.
Next, convinced that Unicode’s U+1361 was unpractical to be used as a _character_ (at the level of the text encoding), I implemented it as an alternate _glyph_ to the regular word space, using OpenType glyph substitution (thus at the level of the font and text shaping). This worked out beautifully, because now I could cheat typesetting engines, taking advantage of common line-breaking algorithms (which not only use word dividers as line-breaking opportunities, but also stretch/shrink them to justify lines). Unfortunately, as word spaces are stretched or shrunk, the OpenType glyph shaping engine, while drawing the colon-like ፡ Ethiopic word divider, is not aware of the available space, which thus is placed unsatisfactory, either to near to the preceding word, or worse, even overlapping the preceding character.
Eventually, I went for a hybrid approach whereby I used a combination of U+0020 + U+1361 + U+0020 (i.e. surrounding the fixed-width Ethiopic word divider with regular, flexible white spaces). While this is an ugly hack (certainly from a puristic text encoding perspective), it practically solves the issue, with nicely spaced-out ፡s in-between words.
Another, related issue concerns the lack of hyphens. Since word boundaries in classical Ethiopic are unambiguously marked with the explicitly drawn ፡, there’s no need to indicate when a word is broken in-between syllables at the end of a line. If a line ends with ፡, the reader will know the next couple of glyphs on the following line will not belong to the preceding word, but form another one. Else, it must be assumed that the syllables following the last ፡ on the line, will form a word together with the syllables on the following one up-to the next ፡. But as no current typesetting software supports this locale, one again needs to find a hackish work-around. I did so, at the level of the font, by putting an empty, zero-width glyph at the U+002D codepoint (hyphen-minus)…
There are some more issues involved with typesetting classical Ethiopic Ge’ez, but word dividers, hyphenation and line-breaking are the toughest.
If you’d like to know more, the W3C has an Editor’s Draft concerning ‘Ethiopic Layout Requirements’ [1], but many of the issues raised remain as of yet unresolved, pending user feedback. I found an Individual Contribution (For consideration by the Unicode Technical Committee) “Proposal to Reclassify Ethiopic Wordspace as a Space Separator (Zs) Symbol” [2] on the Unicode.org website, being very illustrative and offering thorough suggestions for implementation details.
I’d love to discuss these and other scholarly typesetting issues with anyone interested. Do check out my Dodecaglotta side project and get in touch!
With over 600 “fidäls” (graphemes) a fascinating syllabary for sure! While today the Ge’ez language indeed is used in liturgy only, the script is still used by dozens of East-African languages (with up to about 60 million potential users). Astonishingly, there is only a handful of digital fonts available. More interestingly, typesetting classical Ge’ez poses challenges which are not easily solved by current software.
I have attempted a modern type design based on the earliest printed Ge’ez and hacked together custom line-breaking to typeset a piece of the Ge’ez bible (which to-date does not exist in electronic plain text).
> “All devices are used for Mind Control projects run by CIA or other intelligence agencies. A group of researchers (under the name Dr H Loos) were actually a group of hired professionals for researching and inventing such devices which could be developed and used for mass mind control, PSYOPS, behaviour modification later by CIA.”
That Netscape screenshot only shows users have always been able to specify their own font preferences for three generic font families (serif, sans-serif, mono), along with a respective font-size. I’m not objecting to that: in fact, it’s a Good Thing that users are able to take control.
But taking control also means dealing with inconsistencies myself. If I were so bold as to set Impact as my default serif font, then I would also set a considerably smaller font-size to make up for the huge x-height. The thing is: if it would bother me, I, as an end-user, could do so, thanks to the browser’s interface exposing to me the needed controls.
It’s a whole different thing when browsers would start changing default behavior based on ‘common’ properties in ‘most’ fonts, without inspecting the real features of the actual fonts they render. Different, because if it would bother me, as a web developer, I couldn’t do anything about it, because the browser, while deviating from standard defaults, would not offer me the required controls, i.e. would render my CSS rules differently based on opinionated variables I cannot know.
Sure. Badly produced fonts (those you can find on the cheap), tend to have faulty metrics: i.e. the designer did not change the default ones of the font design app (Glyphs, FontLab, FontForge, &c.) they are using so as to match the actual outlines of the glyphs they drew.
E.g. the font’s metrics tell: xHeight=500 and UPM=1024, so we may assume the aspect ratio is 0.48. But then we look at the outlines and see the designer drew the upper most top node of the x at the 600 coordinate on the Y-axis. So, in fact, the actual aspect ratio is 0.59, and thus the metrics are useless indeed…
But again: should we then _assume_ to be always dealing with badly produced fonts? Or could we just expect font metrics to tell the truth? For if we won’t, then we’re totally lost, and will make things even worse for professionally produced fonts, which do honor the specs.
(As for non-Latin scripts: it’s indeed up to the discretion of the font designer how to draw the height of, say, CJK characters or the size of the teeth in Arabic, but always _relative to the xHeight_ as stated in the font’s metadata, so the font behaves consistent with the specs.)
At Textus.io, we therefor rely on the font’s built-in metrics metadata, for now. But since we are obsessed with fool-proof typography, we are indeed considering to look at the actual coordinates of the outlines instead…
I do not expect browsers to do deal with inconsistent font metrics, though. As a developer, I instead want to rely on browsers behaving consistent, being assured they won’t ‘fix’ things I already fixed, for then the outcome will be totally unpredictable. That’s why we have standards and specs after all, haven’t we?
> “monospace fonts tend to be wider, so the default font size (medium) is scaled so that they have similar widths”
> “the base size depends on the font family and the language … Default system fonts are often really ugly for non-Latin- using scripts.”
‘often’, ‘tend to be’: I am worried. I think it’s a really bad idea to deflect default behavior based on such assumptions, certainly when the deviations are a blind process triggered by proxies (like language tags and some vaguely statistical rules-of-thumb for dealing with generic font family names). That is: without even looking at the actual design and metrics of the actual font involved.¹
What happens if the monospaced font in case has a normal x-height and/or an advance-width equal to that of its serif counterpart? What if the CJK and Devanagari fonts have characters drawn already ‘big on the body’?² Then such hard-coded default moonshot-fixes which try to cater for the lowest common denominator will make things needlessly hard to debug and force the designer still to ad-hoc size-adjust font per font, but now also trying to fix the browser’s ‘fixes’. (Too bad: any `normalize.css` wont help…³)
And yet, all of the needed data is available in the font file. There’s even a dedicated CSS property for dealing with fonts’ varying metrics: `font-size-adjust`.⁴ Not that browser makers care to implement⁵, but since the OP’s post concerns Firefox (which does support `font-size-adjust`, but the article does not discuss it) I wonder: is it a matter of performance that retrieving the actual font metadata and metrics is left out of the equation? Surely, the fact that local font files, base64 data-URI embedded or externally hosted ones can be used, makes implementation all but trivial…
At Textus.io⁶ we’re going great lengths to solve typographic issues such as these. Point in case: for each font we read out the `xHeight` value, then calculate the actual font-size relative to the font’s UPM (unitsPerEm), so we have consistent apparent font-sizes, c.q. aspect ratios.
I think it all boils down to a separation of concerns: proportion and interrelated sizes (ascender, caps, descender, x heights, stem width, etc.) are up to the discretion of the font designer, overall aspect size is the business of the typesetter (css stylesheet author), and the browser ought always draw consistently, regardless of generic font family name, language and/or Unicode code range.
Today, 18 July 2017, is Jane Austen’s bicentenary.
Just the perfect day to showcase our product: Textus, a typesetting engine in the cloud.
Generating all of Jane Austen’s Collected Works from scratch (i.e. plain text markdown) into beautiful online ebooks and PDFs is a matter of seconds, instead of weeks…
That mysterious font actually is an adaptation of one of the oldest typefaces around specifically designed for optical character recognition. OCR-B (1968), by Adrian Frutiger. It’s used everywhere still, on credit cards, wire transfer forms, license plates, etc. etc. It’s even an industry standard (ISO 1073-2:1976).
So, it’s as ‘custom’ as Apple’s (pre San Francisco) systemfont Myriad, compared to Frutiger’s Frutiger, who said of the adaptation: “not badly done” while feeling that the similarities had gone “a little too far”… —
https://en.wikipedia.org/wiki/Myriad_(typeface)
tl;dr: ‘… I am convinced that “translating” Euclid into modern algebraic notation is historically destructive … In writing the Illustrated Theory of Numbers, I am trying to give respect to history. … In the style of Tufte …’
Do check out the published page spread previews of this book-in-progress: they’re beautiful!
Looking for something like GeoGebra†, but usable on the Web, I came across this JavaScript library (which depends on d3.js to draw the SVGs). It’s available for Node on npm‡.
What I especially like is the simple, declarative syntax, allowing to draw geometry diagrams in the classic euclidian style, as e.g. in this constructive proof: http://euclid.js.org/parse.html
There are many charting libraries, all focussing on data visualizations and statistical (or data-driven) plots. But a comprehensive library to draw abstract geometry seems to be a desideratum still. There remains much to be desired in this one, Euclid.js, too.
For example, if one would want to draw a diagram based on a rectangle of a given proportion, then, with Euclid.js, the rectangle must be tediously drawn from Euclidian primitives (point, intersection, line, circle, segment) first, before one can actually start drawing the desired figure from there.
Ideally, the drawing library would have built-in convenience constructs for frequently used geometrical figures such as a square, a root-two rectangle, an isosceles triangle, an equilateral triangle, other regular polygons, methods for bisecting a line segment, trisecting, etc. etc. And it would be really nice, if relevant points would be labeled using a system of choice (ABC or ΑΒΓ), and when significant features of the drawing would be shown (segments of equal length marked, right angles, etc.).
Depends on what you want to achieve? When diffing source code, comparing lines, without caring too much about the broader context, may be a good-enough proxy of what you ideally want to compare, which is the program’s logic. But for the latter, you would first have to execute both programs, and diff their parse trees.
Likewise – and perhaps most notoriously – simple line-based diffing does not suffice for diffing prose (natural language text), where knowledge of the broader context, markup (semantics in punctuation and document structure), and paragraph order are crucially important.
Yes we did, and they promised a completely paperless workflow, relying on Dropbox for upload of raw documents (invoices, bank and credit card statements), and proprietary accounting software which would ‘automagically’ fetch, parse (including OCR), categorize, and eventually book those.
They did not maliciously mislead us, but failed on their promise because apparently the ‘automagical’ part does not seem to work out so well. Yet, that, imho, is more the fault of the implementation and of its users (the accountants), than it is because such things are too hard to accomplish with the state of current software development (and ‘AI’).
For one, I found it beyond comprehension that any such software would blindly rasterize well-structured PDFs, as does the software used by our accountant, to then OCR the resulting low-res jpg, while wastefully of resources throwing away most of the relevant information, with obviously bad ‘detection’ results. Worse, duplicate uploads would differ, resulting in double bookings requiring the accountant’s assistant using the software to manually fix those errors produced by the software. In the end we end up with a much more expensive accounting bill than we would have had when we sticked to a paper-based flow.
But is doable, and I truly hope some startup grabs the opportunity to implement it well.
SILE indeed looks great, promising to come on par with the typesetting quality we have come to expect since TeX: Knuth-Plass line breaking, Unicode and OpenType font features support, complete with contextual shaping, Cassowary constraint solver, parallel text, multiple apparati, foot and marginal notes, vertical typesetting… This is a typographer’s dream!
But, like TeX and friends (LaTeX, ConTeXt, etc.), creating stylesheets and document templates still looks like a pain with SILE and alike. At least from the perspective of designers who have come to expect a strict separation of concerns between document structure/semantics and its styling, and who are used to work with a declarative stylesheet-based language like the prevalent CSS, as opposed to the macros of TeX, and its document model which conflates semantical markup with inline styling instructions.
Similar initiatives like SILE, which attempt to port TeX to newer languages while untangling macro spaghetti, like Cló¹ and Rinohtype², didn’t consider CSS-based stylesheets either. Which is a pity, especially with highly developed W3C Working Draft open standard specifications³ for paged media being out quite some time now.
That’s exactly what makes PDF formatters like Prince⁴, which accepts standard html and css as its input, so immensely attractive: users can continue to use the (Web) technologies they already know (html, javascript, css) and enjoy a strict separation of concerns between document contents, templates and make-up. Unfortunately, there exist no FLOSS alternatives.
Once in a while, people are coming up with the question whether there are TeX flavors which do support `.css` as an input.⁵ Peculiar too that no project exists to create a compiler to convert and map css style rules, selectors and properties to something which TeX does understand. (Except may this⁶ one.)
First words of the Bible: בְּרֵאשִׁית, בָּרָא אֱלֹהִים, אֵת הַשָּׁמַיִם, וְאֵת הָאָרֶץ. ‘In the beginning God created the heaven and the earth.’ (Gn 1,1) — Okay, the third verse reads, in French (Bible de Sacy translation): ‘Or Dieu dit: Que la lumière soit faite. Et la lumière fut faite.’ — Not a plural.
The angel of the light = Lucifer (<Lat. ‘light-bearer’); cfr 2 Cor. 11:14: ‘And no wonder, for Satan himself masquerades as an angel of light.’ — I don’t believe Kant could ever have imagined him being associated with satanism…