There are people who will tell you that the Latin letter S is a difficult shape to get right.
Remote
Tiro Typeworks
@TiroTypeworks@typo.social
mastodon 4.6.9Official account of Tiro Typeworks Ltd., a digital type foundry founded in 1994 by John Hudson and Ross Mills, specialising in custom fonts for multilingual publishing and computing.
#Typography #TypeDesign #Fonts #Unicode #WritingSystems #Linguistics #Palaeography #Calligraphy
973 Followers
229 Following
50 Posts
Joined November 06, 2022
Website:
Twitter:
Personal:
GitHub:
Replying to
@svgeesus@mastodon.scot Thanks to this, I just spent the past hour reliving the summer of 2009 via the listserve discussions that led, eventually, to the charter of the W3C webfont working group. I’d forgotten how cheeky I was.
‘An interactive introduction to the terrific experience of rendering Arabic typography and its technical debt.’
https://lr0.org/blog/p/arabic/
Twilight of the Velocipede: typesetting races before the age of Linotype
https://publicdomainreview.org/essay/twilight-of-the-velocipede/
RE: @TiroTypeworks@typo.social
Now thinking a lot about Margaret, who was one of the first people I met in the type business, and who was unfailingly kind and generous with her time. When we met, she was the editor of U&lc, the type and design magazine published by ITC, copies of which are still worth collecting.
When she left ITC, she moved to Portland OR, where she taught design courses. Ross and I visited her when we passed through Portland, but then gradually lost touch. Which, of course, I now regret.
Margaret died in 2019, aged 80, after living several years with dementia, which is so fucking awful. Perhaps I should be thankful that I only remember her as funny, intelligent, and lively: the ex-nun, feminist, and jazz afficianado who introduced me to a collegial community of type folk.
Replying to
Replying to
@letterror @justvanrossum @Bahman The distinction is 100% Adobe’s invention and exists entirely to support glyph-to-character mapping in PDFs distilled from print streams. There is no other reason why the AGLFN, uniXXXX and uXXXXX names and associated _ and . conventions exist. Indeed, this is the only really compelling case for including glyph names in font binaries at all.
I remember the looks of glee from Microsoft and Google folk during a variable fonts working group meeting when I pointed out that the CFF2 table spec meant that it would now be possible to make both TTF and CFF flavour fonts without glyph names (using format 3 post table).
My choice of music isn’t usually directly related to what I am working on. But it’s Gurmukhi time, and I have a playlist of the 100 greatest Bhangra songs.
New update to the Tiro Builder tool, fixing an issue with hinting in CFF fonts instantiated from CFF2 variable build streams.
Just finished testing it on a collection of complex Indic fonts built on-the-fly from multiple sources, and although I know how the builder works and it does what I asked @khaled@typo.social to make it do, it still feels a bit like magic every time I run it.
https://github.com/TiroTypeworks/TiroTools/tree/master/Builder
Replying to
@benkiel @behdad @onpaperwings @tphinney I think this is a hugely valuable technology — especially for the web — that has largely left the traditional professional design market for fonts behind. This doesn’t surprise me, because I still encounter designers who don’t have a clue what they can do with OpenType Layout features with the apps and fonts that they already have, and that technology has now been around for almost thirty years.
We sell far more individual font licenses than we do full family licenses. Most designers only need a couple of weights for a job, so neither a complete static family nor a variable font is economically attractive.
Interestingly, I also see a lot of downloads of individual OFL fonts, even though the whole family/variable is free.🤷
Replying to
@justvanrossum @frankrolf @mathieureguer This example requires something like a reverse Indic shaping engine within the PDF viewer. The arching form from the left is the vowel sign (ikar) that is the last character in the sequence (so needs to be reordered from the beginning to the end). In this font, it is forming a ligature with the hook form above right (repha), which is the first two characters in the sequence (so need to be reordered to the beginning). So that ligature needs to be decomposed during parsing, and then the parts correctly identified and reordered according to rules.
There is no provision within the existing Adobe glyph naming rules for this ligature.
Replying to
@dominika If the letter shapes are composed of individual strokes of the brush, as in brush calligraphy, I would say it is writing. Otherwise, it is painting.
Christopher Miller on the varied roots of quirky sign ordering in Indic orthographies, from @viewsproject@mstdn.party
Replying to
@paulvanderlaan @letterror @justvanrossum @Bahman So, potentially, you could be dealing with three sets of names?
- Original designer names.
- Your production phase names.
- Final font table names.
Replying to
@florian @justvanrossum
‘... if there is a language expert backing it.’
Glyph names are generally script-based, not language-based, and given the technical requirements of fonts are usually most usefully derived from the Unicode character names, even though these sometimes differ from localised names in particular languages. Indeed, Unicode character names may be least useful in this respect when they correspond to language-specific names, as in the case of Sinhala, in which case the informative annotation names are more helpful.
Pondering how many and which glyphs are needed in each script to fully work out a stroke weight and contrast variation scheme. It’s a difficult thing to document while one is doing it, because the ‘fully worked out’ point is either ahead of or behind the current state of the design, and not easy to spot as it passes.
Replying to
@dominika Something like this demonstration by Glen Weisgerber is easily classified as writing, while the tool and the medium are paint, and he talks about ‘sign painters’.
https://www.youtube.com/watch?v=y3WZNSGBsoc
Single Stroke Lettering Demo by Glen Weisgerber
Replying to
@dominika Either way, I would say that you’re not drawing letters with a brush unless you are painting outlines rather than shapes.
[In this distinction, I follow my father. I remember him shocking a group of onlookers at the National Gallery in London, before Leonardo da Vinci’s ‘Virgin of the Rocks’, dismissing it as ‘Not really painting.’ He meant that Leonardo was primarily a draftsman, and this was a kind of coloured-in drawing, in contrast to e.g. Titian who is building up an image from layers of paint.]
Replying to
@letterror @timahrens @justvanrossum Yeah, that’s what I’m getting at, I think.
Just’s animated visualisation really nicely shows how stretching a complex web of axes in one dimension alters the distances between intersections within that web. But that’s not what happens when one changes the unit scale of a variable font axis. The design space isn’t being stretched. You’re just changing the resolution of that axis. The design space is bounded by the glyphs not by the numeric length of the axes connecting them. You only change the shape of the design space if you change the glyphs or their relative locations (e.g. redefining an axies extreme or the relative location of an intersection, either in the masters source or via avar).
Replying to
@justvanrossum @frankrolf @mathieureguer Here’s an example. The orange glyph is a ligature of the base consonant and the vowel sign, which are at opposite ends of a character cluster sequence. It’s possible to imagine a sophisticated glyph-name-to-character-string parser being able to handle this using algorithmic rules to reorder its output back to the correct character sequence, but to my knowledge none do this.
@nedley@pdx.social Testing some calt feature contextual shaping in Devanagari. When a half form is forced with ZWJ before the –tra rakar form, I want to contexutally substitute a variant form of the latter that connects more aesthetically with the preceding half form. This calt substitutiion is working in HarfBuzz, but not in CoreText, so I am looking for a clue why this might be?
[I am using calt, not rclt, because some users may want to disable this substitution because of what they’re used to seeing in other fonts and legacy documents influenced by typewriter output.]
Replying to
@nika@typo.social @kentlew@typo.social Very strange. I’ve not seen this behaviour.
Pinging @tphinney@typo.social who often has insights on FL queries.
Replying to
@dominika I don’t think there are ‘correct terms’, only more or less useful ways to talk about things. It is often useful to be able to make distinctions by using different words to mean different things, but sometimes words gravitate to being synonyms. I think that is where writing and painting are with rergard to brush lettering: it isn’t easy to make a useful distinction between them, such that one could look at any given piece of lettering and say ‘This is painting’ or ‘This is writing’.
Then, sometimes, someone like Titian comes along and uses a medium in a way that changes our understanding of that medium, and potentially our terminology (although most people still call the da Vinci work a painting).
Replying to
@onpaperwings @jesserewing @glennf I’ll second that. I have a collection of friends’ PhD theses printed by Lulu, and the quality is good. There is a range of options for paper weight and finish, and for binding.
Replying to
@lowtech @gdc That’s not a thing in current font formats for general typography. You may be remembering one of any number of online discussions about banded/bubble kerning, dating back to at least the comp.fonts Usenet group in the mid-1990s.
The closest thing to an implementation of this at the font data level would be cut-in kerning for OpenType math typesetting.
cf. https://learn.microsoft.com/en-us/typography/cleartype/pdfs/cambriamath.pdf
Replying to
@xotypeco Yes, this is a communication or customer education issue, but it comes from thinking about cost instead of thinking about value. The usage rights licensing model for creative work derives fees based on the (potential or realised) value to the customer. If a customer is thinking in terms of having paid for a *thing* (e.g. the font they download), they’re not thinking about paying for different ways of using that thing and the multiplcation of value they derive from those uses.
Usage rights licensing is specifically a response to ease of reproduction: the more easily reproduced something is — and copying a digital file is about as easy as it can get — the less material or inherent value the thing itself has. But the *use* of the thing may have huge value.
Replying to
@justvanrossum @timahrens @letterror As Erik wrote above re. a 4-master 2-triangle square, there are two ways of placing the triangles, so I’ve been presuming that the triangulation is explicit at the tool level and not automated based on shortest distance.
I am also presuming that axes are normalised, so every two dimensional designspace is actually a square, every three dimensional designspace is actually a cube, and every four dimensional designspace is actually a mindfuck.😁
Replying to
@timahrens @letterror So, to go back to your earlier statement regarding the weight axis:
‘Had they decided that 40 is regular and 70 is bold then our interpolated fonts would look differently.’
Would they? We’d still have axis extrema glyph designs that are conceptually and nominally regular and bold. And (user facing value) of 500 or 50 on the different scales would be the same relative distance between those extremes, resulting in the same interpolation result. The only difference between the axes is their resolution. In the one axis the user can address ten times as many integer locations as in the other.
Replying to
@fontra @khaled Re. the GPOS compilation: Indic shapers do not use the mark and mkmk features, so ideally there would be a way to specify at the anchor level to which feature an anchor should be compiled, rather than presuming mark or mkmk. Even better, it should be possible to define layout contexts at the anchor level, and to control lookup ordering at the anchor ordering level.
[These comments are not specific to Fontra, of course. All font editors would benefit from this functionality, and from corresponding updates in the UFO and other source formats to finally drag OTL out of the AFDKO .fea bucket and properly integrate in design sources.]
Replying to
@ksmallgallery Check whether records for the foundry exist and are accessible. The release date of the typeface will give you the earliest possible date of the specimen, and is often a good approximation of the specimen date for single face/family specimens.
Replying to
@kentlew @ksmallgallery Yes, Brill has these. They’re included in both the complete Brill fonts and also in the Brill Latin subset family, so the latter would be a cheaper option if you don’t need other specialist stuff such as IPA, obscure historical characters, or the Greek and Cyrillic.
https://www.tiro.com/fonts/brill
Replying to
@davidsudweeks @tphinney @timahrens At the character level, the text is still a period followed by an ellipsis, not a series of periods.
Replying to
@iorsh @tphinney @timahrens The result would be the same: four evenly spaced dots.
One could get fancy and contextually kern the dot spacing depending on whether the sequence is preceded by a letter... or by a . . . space.
Replying to
@Hilary@typo.social @justvanrossum@typo.social This is actually one of the more useful ways to use AI: to see what is the most reductive, cliche, and uninteresting use of a term.😜
Replying to
@timahrens
‘as different point pairs are considered “close to each other”‘
Meaning rounding happens differently in any area/volume/banzai* between the axes, yes?
*Yeah, I just used banzai as a generic term for any multidimensional space.
Replying to
@timahrens @letterror The interpolations should remain identical at the scaled intervals along that axis, but changing the axis scale is also adding or removing intervals, and that unavoidably affects the addressable design space between the axes. That’s already the case in OTvar compatible design spaces, so is the problem significantly different in the kind of non-orthogonal design space Erik is illustrating? Or are you pointng to this as a general problem of multi-axis design spaces?
Replying to
@wtrmt@mastodon.social @simoncozens@typo.social Oh, it was Papyrus the font that I gave as a prompt. The background texture was just ChatGPT being extra literal.
Replying to
@morningtype Congratulations.
What”s the process for correcting or expanding information?
Replying to
@dominika Agreed.
John Stevens provides a really good demonstration of brushed Roman capitals, showing how rotation of the brush is used to form serifs and blend curved strokes. His techniques follow quite closely those developed by Father Catich from his analysis of inscriptional lettering in Rome. Easily classified as either writing or painting, and not what I think most people think of as drawing.
https://www.youtube.com/watch?v=IuXDJkR6fZg
Brush Roman Demo by John Stevens
Replying to
@justvanrossum @frankrolf @mathieureguer I’m thinking through repha identification, and it is perhaps more algorithmically simple than I thought.
In this case, the first glyph in the string is the ikar + repha ligature. If this were named in a way that actually ignores the underlying character order, as /uni093F0930094D, then it would decompose to ikar + ra + halant, and simply reordering the parsed vowel sign character to the end of the cluster would leave the ra + halant where they belong at the beginning of the cluster.
In most other cases, the repha is going to be at the end of the glyph string, so then the parser needs to idenfity a trailing ra + halant at the end of a conjunct as a special case and reorder them to the beginning.
Replying to
@justvanrossum @frankrolf @mathieureguer Obviously, such a sophisticated parser needs to understand the possible inclusions and limits of an Indic cluster, and be able to reverse the glyph output ordering of an Indic shaping engine. There are very likely some ambiguous sequences that have not occurred to me yet.
Replying to
@wtrmt@mastodon.social @simoncozens@typo.social First, this made me wonder what the Bangla script would look like in the style of Papyrus.
And then, because it is 2025, it made me wonder what ChatGPT would think the Bangla script would look like in the style of Papyrus.😜
Of course, the result is exactly what one would imagine. I love how even the gaps in AI’s understanding of what non-European writing systems look like are utterly predictable.