Presentations from ATypI 2006 Lisbon conference & TypeTech
I promised a number of folks that I would make my recent presentations at the international typography conference, ATypI, available. So here are my presentations and those of several colleagues from ATypI 2006 Lisbon. What is the ATypI conference? I wrote about it a bit in this post on font conferences.
First, a cautionary note: these are the *slides* from the presentations, usually not including talking points. So many of these will be of most use to people who were there. Also, I will continue to add TypeTech presentations to this post as more come in.
Main Conference:
- Character Set Journeys (450K). This was my presentation from the main conference, about the evolution of character sets and how they keep on expanding. The final bit covers some info on Adobe’s SING technology, though that is covered in more detail below.
TypeTech Forum
- CSS-based font menus, Windows Presentation Foundation, and OpenType 1.5 (160K). A pretty dense presentation with enough detail on the slides to be a useful reference. I suggest reading this first, and then digging into the upcoming Microsoft white paper on the subject (not yet available as of this writing). This presentation is not a complete reference on the issue, but it’s a solid introduction.
- Advanced MM theory (300K). Only mildly helpful unless you also saw the presentation – this was accompanied by demos and extensive explanations.
- Is it okay to lie? (in a font) (100K). Just a couple of slides, not very useful unless you were there.
- Intro to SING technology (150K). SING is Adobe’s “next big font thing,” a technology for dynamically extending fonts on the fly. Slides are pretty useful even without the talk track.
- Sweeping overview of OpenType support (3.7 MB) and limitations in applications and operating systems, by Juergen Willrodt. Note that I can’t vouch for the accuracy of every single element of this presentation, though I believe there are few if any errors.
- OpenType feature files (625K). Christopher Slye’s talk on OpenType feature files and some interesting issues that may arise. Moderately useful as a stand-alone piece, but there are a number of bits that you really had to be there for, or where he did a separate demo.
- Adventures in Class Kerning (160K). Miguel Sousa’s take on this perennial issue was a welcome break from having me or Adam Twardoch do it. Miguel mostly focuses on using FontLab, though with some FDK content. The presentation is moderately useful, but there was a lot of demo/explanation that is not captured here.
7 Responses
Comments are closed.
Thanks a lot Thomas!
Thank you for providing the documents.I have been studying the SING intro TypeTech.pdf document and feel that I am learning a lot.On page 9 is mention that the glyphlet can contain a .notdef glyph.I have been thinking about this and am wondering whether the person setting type using a font which has been augmented using a glyphlet will be able to have access to the .notdef glyph of the glyphlet during the typesetting process.If so, there opens up the possibility that the .notdef glyph of a glyphlet could be used as a glyphletmaker’s mark, thus opening up interesting artistic possibilities for glyphlet designers as the .notdef glyph of the glyphlet would not be needed for the usual .notdef role of indicating that the font cannot supply a glyph for a requested character.When using a font augmented by many glyphlets such a facility would allow the typesetter to view the various glyphletmaker’s marks if desired.This could certainly be a fun artistic thing yet could also potentially have a practical use as a glyphletmaker could choose to have a selection of marks as variants of his or her basic design, perhaps indicating things such as small capital and ligature and swash alternate as the glyphletmaker chose so as to convey information to the typesetter in a graphic manner.William Overington11 October 2006
thank you for making this information available, Thomas!
William,Short answer: I don’t think that’s a workable idea.The long answer also follows. (Thanks to my colleague Daan Strebe for verifying some of my assumptions.)At the moment no implementation exposes the notdef, so it would only be visible to someone who opened the glyphlet with a glyphlet editor or something like that.Information about how the glyphlet relates to a font is already stored in the glyphlet. For example, if a glyphlet is a ligature, detailed information on that is already present in the glyphlet. So is the identity of the glyphlet maker. Bits of metadata such as these are exposed in the Adobe SING Glyphlet Manager (ASGM).Also, if the notdef *were* to get used, one would probably want it to function as a notdef. Co-opting it for some completely different purpose seems like a Bad Idea, on principle.Regards,T
I have been continuing to study the documents, in particular slye_lisbon-05.pdf and have thought of an interesting possibility.Suppose that an abstract logo glyph is devised for a Private Use Area code point.Is it possible to produce a glyphlet which contains the glyph, is mapped to the Private Use Area code point and has a language system such that the glyph is substituted with a sequence of glyphs dependent upon the language being used?For example, if English is being used, then the following sequence is displayed.It is snowing.There being two space characters after the full stop.However, if French is being used, then the following sequence is displayed.Il neige.There being two space characters after the full stop.If the above is possible, then by using several glyphlets, each for one sentence, a small system for conveying messages composed of preset sentences that are displayed in the language of choice could be produced.For any one code point there could be a glyphlet which contains the sentence in many languages, yet there could also be a glyphlet for just one language.If the sentence localization could be done before ligation and swash letters are applied according to the rules of the font with which the glyphlet is being used, then not only would language localization be achieved yet fine typography could be produced as well!Now, there are many, many sentences which could be devised and this is just using the Private Use Area.Yet, suppose that preset sentences for use in such areas as weather reports, travel information and e-commerce were devised, tested out in the Private Use Area and, if it all works as well as this thought experiment suggests that it might, were encoded in plane 7 of the Unicode code space, which is presently unused. It would then be possible for people to produce glyphlets for their own language for all or a subset of the formally-encoded preset sentences.There could also be preset sentences for such things as international poetry and for some aspects of e-learning.In addition, there would remain the possibility of using the Private Use Area for special-purpose sentences by private agreement.An important factor is how many glyphs can be in the sequence of glyphs within the OpenType rule.For example, the English sentence above needs sixteen glyphs including four spaces: the French sentence above needs eleven glyphs including three spaces.Yet these are short sentences. How many glyphs could be in such a rule please?William Overington16 October 2006
I sent in a further comment to this story ten days ago and it has neither appeared nor has an email saying that it has not been selected for inclusion in the blog been received, so I thought that I would send it again in case it has got lost.I feel that this application of glyphlet technology is potentially a big thing as if it can be implemented using standard OpenType and glyphlet technology it can be developed without new software packages being needed to use it and thus could be used with some existing OpenType-aware applications.It would be great if Adobe would like to try it out by implementing some glyphlets to demonstrate the idea and to show that it works and to try it out in applications please.I realize that this would potentially move ISO 10646 / Unicode forward dramatically into uses not presently intended for it, yet such is progress.William Overington26 October 2006
Sorry – I was travelling (UK and Las Vegas) and didn’t get through my comments for a few days there.I suspect that what you suggest is technically possible – it is certainly technically possible in OpenType, whether or not it is possible in SING.I don’t know that I’m easily convinced it would be useful or make sense, nor am I likely to put energy into testing it – but of course both SING and OpenType can be used for a pretty wide range of things, not all of which are what “purists” like me would support.On a broader issue, the current implementation of SING requires that applications be actively aware of and support SING. Even a system-level implementation of SING would probably require a certain level of active application support. The notion that the glyph complement of a font could change while the font is installed and the application is running is more than a little alien to most applications.Regards,T