Entries tagged with ‘web typography’

Display:

Tags

  1. Reversed Logotype

    Reversed type optical illusion example.

    This image shows a particular optical illusion that confronts us every day. Notice the difference between the black text on a white background and the reverse. With reversed type — light text on a darker background — the strokes seem bolder.

    Black text on white is very familiar, so we can be forgiven for thinking it correctly proportioned. For familiarity’s sake we can say it is, but there are two effects happening here: The white background bleeds over the black, making the strokes seem thinner. With reversed type the opposite is true: The white strokes bleed over the black, making it seem bolder.

    Punched, backlit letters on a sign outside the Nu Hotel, Brooklyn.

    One of the most obvious examples of this is with signs where the letters are punched into the surround then lit from inside. In his article, Designing the ultimate wayfinding typeface, Ralph Herrmann used his own Legibility Text Tool to simulate this effect for road and navigational signs.

    One might say that characters are only correctly proportioned with low-contrast. Although objective reality hails that as true, it isn’t a good reason to always set type with low contrast. Type designers have invariably designed around optical illusions and the constraints of different media for us. Low-contrast text can also create legibility and accessibility problems. Fortunately, kind folks like Gez Lemon have provided us with simple tools to check.

    As fascinating as optical illusions are —  the disturbing, impossible art of Escher comes to mind — we can design around reversed body type. On the Web, increasing tracking and leading are as simple as increasing the mis-named letter-spacing and line-height in CSS. However, decreasing font weight is a thornier problem. Yes, we will be able to use @font-face to select a variant with a lighter weight, but the core web fonts offer us no options, and there are only a few limited choices with system fonts like Helvetica Neue.

    Reversing a logotype

    For logotype there are plenty of options, but it makes me slightly uncomfortable to consider switching to a lighter font for reversed type logos. The typeface itself is not the logotype; the variant is, so switching font could be tricky. Ironically, I’d have to be very sure that that was no perceivable difference using a lighter weight font. Also, with display faces, there’s often not a lighter weight available — a problem I came across designing the Analog logo.

    The original Analog logo seen here is an adapted version of Fenway Park by Jason Walcott (Jukebox Type).

    Analog logo original.

    The logotype worked well when testing it in black on white. However, I wanted a reversed version, too. That’s when I noticed the impact of the optical illusion:

    (Reversed without any adjustment.)

    Analog logo reversed (flawed).

    It looked bloated! Objective reality be damned; it simply wouldn’t do. After a few minutes contemplating the carnage of adjusting every control point by hand, I remembered something; eureka!

    (Reversed then punched.)

    Analog logo reversed (punched).

    Punching the paths through a background image in Fireworks CS4 removed the illusion. (Select both the path and the background then using Modify > Combine Paths > Punch.) Is this a bug? I don’t know, but if it is, it’s a useful one for a change!

    Modify > Combine Paths > Punch in Fireworks CS4.

    N.B. I confess I haven’t tested this in any other Adobe products, but perhaps you will be so bold? (’scuse the pun. :)

    Fireworks CS4 screenshot.

    Matthew Kump mentions an Illustrator alternative in the comments.

    I grinned. I was happy. All was well with the world again. Lovely! Now I could go right ahead and think about colour and I wouldn’t be far from done. This is how it emerged:

    Analog logo.

    A final note on logotype design & illusions

    Before we even got to actual type for the Analog logo, we first had to distill what it would convey. In our case, Alan took us through a process to define the brand values and vision. What emerged were keywords and concepts that fed into the final design. The choice of type, colour, and setting were children of that process. Style is the offspring of meaning.

    I always work in greyscale for the first iterations of a new logo for a few simple reasons:

    1. The form has to work independently of colour — think printing in greyscale or having the logo viewed by people with a colour-impairment.
    2. It allows for quick testing of various sizes — small, high contrast versions will emphasise rendering and legibility issues at screen resolutions, especially along curves.
    3. I like black and white. :)

    I realise that in this day and age the vast majority of logos need to perform primarily on the Web. However, call me old-fashioned, but I still think that they should work in black and white, too.

    Brands and display faces emerged with consumer culture during the 19th Century. Logotypes were displayed prominently in high streets, advertising hoardings, and on sign boards. In many instances the message would be in black and white. They were designed to be legible from a distance, at a glance, and to be instantly recognisable. Even with colour, contrast was important.

    The same is true for the Web today; only the context has changed, and the popularity of logomarks and icons. We should always test any logo at low resolutions and sizes, and the brand must still have good contrast (regardless of WCAG 2.0) to be optimal. A combination of colour and form works wonders, but in a world of a million colours where only a handful are named in common parlance, having the right form still seems a smarter choice than trying to own a palette or colour.

    A final word

    This article was prompted by a happy accident followed by a bit of reading. There are many references to optical illusions in design and typography books. The example image at the start of this article was inspired by one found in the excellent Stop Stealing Sheep and Find Out How Type Works by Erik Spiekermann and E.M. Ginger. There’s also plenty of online material about optical or visual illusions you can dive into. There’s also more on how the eye processes light. Oh, and don’t forget the work of M. C. Escher!

    Human eyes are amazing. In two sets of watery bags we get a wide-angle lens with incredibly sharp focus and ridiculous depth of field. Apparently our brain is even clever enough to compensate for the lag in the signal getting from retina to cortex. I know next to nothing about ocular science. Spending a morning reading and thinking about optical illusions, and contemplating my own view here in the garden office is pretty awe-inspiring. If only my photographs were as good as my eyes, illusions or no.

    Share

  2. SkillSwap Goes Typographic

    Right. I’m blitzing this. Two posts in one day. It’s unheard of! I’ve finally managed to put up my slides together from SkillSwap Goes Typographic:

    The night was fun and informal — heaps of people thinking, talking, and asking about web typography; a treat! The Clearlefties were great hosts in the day, and a special thank you goes to James Box for looking after and inviting me, and to Natalie Downe for helping James organise a fun, relaxed night. The pub inevitably followed with more type talk, and Señor Richard Rutter generously gave me a bed for the night in his fantastic house. The walk to the office in the next morning along the seafront was also a treat. Almost as good in fact as riding the travellators at Gatwick when changing trains on the way there and back.

    Rich’s Facing up to Fonts talk had a lot of very well-researched detail about the technical aspects of web typography. I recommend downloading the slides. Mine had some food for thought and a bit on technical legibility. Between us we seemed to cover quite a lot of ground. Thanks for all the kind feedback both on and offline. Hopefully, I’ll make it back sometime and share a few drinks with the fantastic Brightonians again.

    Coming up on Saturday at SxSW, there’ll be more typographic musings from Richard Rutter and nefarious others including myself at Quit Bitchin’ and Get Your Glyph On. I tagged them good in the previous post. If you’re going to be in Austin, say hi!

    Share

  3. PHP Advent Seasoning

    Ladies and gentlefolk, I give you the two-thousand and eight PHP Advent Calendar!

    PHP Advent Calendar screenshot.

    As an aside in a season that gets rudely interrupted every year with a huge, great party, the PHP Advent Calendar is adding to the fray. Some of the denizens of PHP are sharing their wisdom from a beat-up old soap box in our quiet, geeky corner of the Web.

    The entire project was launched in a mad, two-day rush, which featured the guys with real talent setting up the server, propagating the DNS, and gathering the initial content. A couple of days after the first article, for my sins, I applied some style to the interface. Twenty-four hours of key-smacking later — and with a good dose of help from the indomitable Jon Gibbins — it was done.

    The project is edited by Chris and Sean with nuts and bolts help from Jon. It is kindly sponsored by OmniTI. I have to tell you, with almost no time to get it done, deadlines looming, colleagues sweating, and the world in general turning far too fast, I’m pretty pleased with the result.

    A single typeface is used throughout. It changes depending on availability, but this seemed like a good opportunity to stretch a face or two. (Writing that made me smile.)

    Although we would have loved to license and use various typefaces not currently available in operating systems, there just wasn’t the time. Without knowing the full range of glyphs the content might need, the faces currently licensed for @font-face linking (many with slightly abridged character sets) might not have had the range we need. So, I chose Baskerville as the primary face with various fall-backs from there. Hopefully the epidemic of the Baskerville italic ampersand will ebb soon, but there are many worse things in life to see on an almost daily basis.

    You might notice the use of the golden ratio, and an attempt to coerce our awkwardly independent browsers into rendering a baseline grid.

    As always, the content was king, queen, barkeep and god: I veered away from images as decoration, considering them unnecessary. I hope nothing overshadows the reading experience. With that in mind the interface is fluid, with a minimum width to stop it all collapsing into a narrow abyss. Most significantly though, the content is genuinely interesting. There are some choice pieces over there, and if you’re interested in PHP at all, swing by, grab the feed, or follow ‘phpadvent’ Twitter for fast updates.

    Share

  4. Display Type & the Raster Wars

    ClearType is 10 years old this Autumn. For most of that time it lay hidden until Vista brought it to the fore by default. Font rendering in Internet Explorer using ClearType is good for body copy at smaller sizes; it’s a huge improvement on the Standard rendering that preceded it. However, larger display text is badly rendered. I don’t say it lightly, but every time I load a page for testing in IE7, I wince at the jaggies. What makes this worse is that Standard rendering is better at display size anti-aliasing. I used to compose scales and size headers to take advantage of smoother Standard rendering at larger sizes.

    The context in which I view the text has the most influence over my reaction: Apple. I use a Mac. My browser of choice is Safari which uses OS X’s native ATSUI font rasterisation engine. Text is as beautiful as it can be on the Web right now. If text rendering in Firefox is disappointing in comparison because of the added weight, rendering in IE on Windows is positively distressing.

    The quality of the rendering is dependent on various factors like the display type (LCD or CRT), the display resolution that has limited pixel density, the rendering engine itself, and the quality of the font file — specifically the hinting of the typeface.

    ClearType was launched in 1998 at COMDEX by a celebratory Bill Gates. In a press release, the director responsible for the ClearType project, Dick Brass, was quoted as saying:

    ClearType makes inexpensive screens look as good as the finest displays, and it makes the finest displays look almost as good as paper.

    If only that were true. OK, it’s a press release, so we assume a degree of hyperbole from exaggerateers, AKA marketeers, writing the copy. But still. Let’s look at the evidence. I built a quick test suite using Georgia, Verdana and Arial because they’re some of the more commonly used Core Web Fonts. Here are screenshots of a heading set in Arial at 36px in different browsers:

    1. IE7 with ClearType on XP Pro:

    2. IE7 with ClearType on Vista:

      Sample thanks to Ryan Brill (he was the first of many kind replies via Twitter). Thanks, all!

    3. IE6 with Standard on XP Pro:

    4. Firefox 3 OS X:

    5. Opera 9 OS X:

    6. Safari 3 OS X:

    Compare the jaggies and dire anti-aliasing in IE7 using ClearType with the Standard Windows rendering of IE6. Also compare the heavier weight of Firefox using its own platform-independent engine with that of Safari using ATSUI.

    Factual insights about the differences from professional font, browser, or raster engine developers would be welcome in the comments.

    One of the reasons for the glaring difference between IE and Safari is a fundamentally different approach to web typography from Apple and Microsoft. Apple tries to render type as true to the original typeface design as possible, Microsoft uses grid-fitting when rasterising a font. There’s more in a previous article for those interested. Studies have shown ClearType to be more legible than Standard rendering, but they only compared the two. Expanding the study to test Macs and Linux-based PCs, as well as ensuring the test group was populated equally by people who use machines other than Windows PCs, would have all helped the results be more interesting.

    Type rendering anomalies are a serious issue for web design. Designers and clients with an eye for detail want typefaces to render accurately and smoothly. Shaun Inman is right:

    Until anti-aliasing discrepancies between platforms can be resolved I don’t see even a standardized approach being accepted by discerning designers.

    ClearType fails to deliver good anti-aliasing. In my view it is a backward step from the old Windows Standard rendering. I am at a complete loss to explain why it is allowed to persist. Especially because Microsoft Typography seems packed full of experts in the field. Surely they’ve noticed?

    Typography on the Web should at least equal the sophistication of print typography, if not enrich it. To do so, type needs to be rasterised correctly, and web designers need the ability to set it with much of the same subtlety and detail available in print. Until that time, technologies like Flash, PDF, and hacks like embedding type in images, will continue to thrive. Designers will use them not just because they ‘do type better’, but because they won’t have to deal with painful inconsistencies between user agents; the bane of the browser wars, and in this instance, the bane of web typography in what seems like the age of the raster wars.

    Share

  5. @font-face in IE: Making Web Fonts Work

    All Hallows’ Eve seems the perfect time for something a little spooky. Getting @font-face working in IE may just be spooky enough. As you probably know @font-face already works in Safari 3 via WebKit and is supported in the latest Firefox 3.1 beta. With IE, that means around 75% of the world audience could see custom typefaces today if their EULAs allowed it. Fortunately, there are good free faces available to us already, as well as some commercial faces that permit embedding. Fontin is one of them and I’ve built it into this example page:

    Before we get into the nitty-gritty of making this work, which you can skip to if you wish, I thought a little history and a brief summary of the current status of the web fonts debate might be useful.

    Web Fonts: Then & Now

    Web fonts have been with us for a decade. They were an original part of the CSS2 recommendation in 1998. Recently, the godfather of CSS, Håkon Wium Lie, brought them sharply into focus with articles in CNet and A List Apart. The ironic thing is, IE has supported web fonts using the Embedded Open Type (EOT) format since 1997. The problem was that EOT was a proprietary format, belonging to Microsoft. Not for much longer: it’s been submitted to the W3C and is going through the process towards becoming a web standard.

    Since the debate opened up, the web and type communities have both been busy discussing how the future will unfold. More collaboration between the disciplines would be beneficial to both, and I’d encourage any interested designers or developers to get involved with organisations like the Association Typographique International (ATypI).

    Recently, Bert Bos of the W3C paid a visit to the ATypI Conference in St Petersburg to meet with type designers face to face. His summary of the current situation is essential reading. The debate has continued apace on the ATypI mailing list, which unfortunately has no public archives. However, if you are member of the ATypI, you can see this summary about the conference panel on web fonts by Nadine Chahine that started the debate in earnest. Simply put, type designers seem anxious about @font-face linking making it too easy to steal a font. Both Microsoft’s EOT format and direct font linking are under consideration with EOT a favourite with many. However, rather than paraphrase a wide-ranging set of opinions, I’d encourage you to join the ATypI yourselves as designers and developers to participate or observe.

    If you have other favourite comments or posts about the future of web fonts, please add them to the comments.

    As a designer, I want a straightforward way of licensing and including fonts for my work. I will pay, respect the rights of type designers as I expect mine to be respected, then get on with the glorious business of merging content with type. It’s not as simple as it sounds, though. The licensing of fonts, and the protection of the rights of smaller designers in particular, is a sticky issue. DRM does not work, so what then? Richard Rutter has shared thoughtful insights which are very much worth a read. My view is that I would be perfectly prepared to pay a separate or extra licence fee to use quality fonts on the Web. I would have no problem selling this to my clients. Embedding or linking to fonts has to be straightforward though. I get paid to think about, plan and implement design, not grapple with obstructive software (more on that later). If fonts were delivered through a third-party web service as Richard suggests, the one proviso must be that it would have to be done by someone who knows exactly what it means to scale a service for millions of users. Like most designers though, I have very little knowledge of the real security and scalability issues, but hope to see a comment from a real security expert, shortly.

    User agents are currently taking divergent routes. Bert Bos’ summary reports:

    Mozilla has stated that they don’t want EOT. But they are not opposed to letting the browser check the license, as evidenced by the proposal to let HTTP headers carry license data.

    Microsoft has said that it is impossible for them to support linking to native OpenType as long as font vendors oppose it.

    Apple’s Safari has implemented font download with no checking of licenses. They said they are against EOT, but would not be against browsers checking licenses, e.g., using Mozilla’s proposal.

    Opera remarked that there are more existing and announced implementations for downloading native OpenType than for EOT. They conclude that the market apparently doesn’t need EOT and thus they see no need to support it themselves either. W3C’s limited resources should be spend on more important standards.

    That means that designers and developers have the same perennial problem: Two different implementations to achieve the same result. Safari 3 and Firefox 3.1 beta both support direct linking to OpenType (.otf) font files. Presumably Opera will soon. Only IE 4 to IE 7 support Embedded Open Type (.eot) files. IE8 does not, but will at some point. So, to see Fontin display in standards complaint browsers like Safari 3 and IE, we need to provide two separate fonts.

    @font-face Example

    The @font-face example uses Fontin Regular by Jos Buivenga — a free face kindly provided by Jos with a licensing permitting embedding with attribution. Jos also has many other fine faces available via his foundry site, Exljbris. The example is a quick one using a traditional scale, with all of the CSS available in the <head> of the file.

    1. Set the basic font-family:

      h1, h2, h3, p, td{
      font-family:'Fontin-Regular', georgia, serif;
      }
      

      Notice the 'Fontin-Regular' name — this is an arbitrary name that can be whatever you like. All it does is tell the browser when to apply the font file referenced in the @font-face rule.

    2. @font-face and .otf for standards compliant browsers:

      Ed: White space inserted for clarity.

      @font-face{
      font-family:'Fontin-Regular';
      src: url('Fontin-Regular.otf') format('opentype');
      }

      Note the 'Fontin-Regular' name, again. This rules basically tells the browser, when the @font-face is set to 'Fontin-Regular', use the font found at this URL.

      Screen sample of Fontin Regular in Safari 3 set at 16px with 24px line height from the example:

      Fontin in Safari 3

      When Safari renders the page, it will look for the font file, then render the text accordingly. There’s a slight delay as WebKit works. In the example you might notice that the text not requiring the loading of a font file renders quickly, but the rest is blank until the browser catches up. For reference, the Fontin-Regular.otf file is 32KB in size. Some font files can be much larger.

    3. Create the .eot file with WEFT:

      To do this you will need to download and install WEFT3, a Microsoft application for creating EOT files from TT fonts. WEFT is not able to create EOT files from an OTF. It must be converted to a TrueType file, first. WEFT is the only tool for this as far as I’m aware, although I believe there is an open source one in development. If it wasn’t for WEFT, embedding EOT files would be easy. What I want WEFT to do is convert the font to EOT, and allow me to create a subset if required. It does that, but in a nightmarish, frighteningly over-complicated way. Perfect for an All Hallows’ Eve entry. Here are a few tips I learnt the hard way:

      1. WEFT requires the URL of the page or site where the EOT font will be used. It will then ‘scan’ the pages by crawling the site to see what glyphs are used and try and create a subset of the EOT file accordingly. If it refuses to analyse a valid URL as it did for me, get granular and specify pages or sub-directories in your information architecture.
      2. If you’re using WEFT via Parallels and XP Pro, it may refuse to add some fonts in your windows/fonts directory to its database of available fonts. Try using a standalone PC if you can. I haven’t tested in any other virtual machine.
      3. Use the wizard to set up your project, but after that try it manually using the View menu item to see what fonts are available to convert, and the Tools menu item to convert them.
      4. WEFT will try to save the EOT file to a remote location. You can over-ride this manually to save the file wherever you please for you to upload yourself.
      5. Disable your original OTF fonts on your system before testing (obvious but worth a prompt).

      Be warned, WEFT is awful to use, in every way. It did not work for me running Parallels with XP Pro on a Mac. 7th Nov: After more experiments, Weft will accept TrueType (.ttf) files in Parallels. It also worked with the gracious help of Jon Gibbins and his standalone PC running XP Pro. Because it is so painful, I cannot give support for WEFT. You can try the Microsoft WEFT user community, but I can’t comment as to its usefulness, and I could not find any other support avenues.

      Hopefully, you now have an .eot file to use.

    4. @font-face and .eot for IE using conditional comments:

      Ed: White space inserted for clarity.

      <!--[if IE]>
      <style type="text/css” media="screen">
      
      @font-face{
      font-family:'Fontin-Regular';
      src: url('Fontin-Regular.eot');
      }
      
      </style>
      <![endif]-->
      

      These are screen samples from IE:

      Screen sample of Fontin Regular in IE6 set at 16px with 24px line height from the example:

      Fontin in IE6

      Notice the bar missing from the capital ‘A’ towards the end of the second line. The tyepface designer, Jos Buivenga is currently looking into the font hinting, with input from John Boardley.

      IE7 sample:

      Fontin in IE7

    See a full size Safari 3 screenshot, and IE6 screenshot on Flickr.

    That’s all! Try the example in different browsers to see how it works for yourself (but please don’t blame me for ClearType’s poor anti-alias at larger font sizes).

    Summary

    We have only a few web fonts with a EULA that permits embedding right now, unless they are free. Please respect the EULAs of any typefaces you try out until the type community resolves the issue for all commercial fonts.

    My feeling after doing this is that EOT has potential advantages in file size over OTF, but OTF files could always be edited (as far as I’m aware) to create subsets just like EOT. Although EOT is not a DRM solution per se, it feels like one. If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long.

    What we need to encourage designers and developers to use EOT today is a good tool to create EOT files in the first place. Perhaps even one hosted remotely, where we can buy a licence, convert the font to EOT, grab the same OTF subset for complaint browsers, and get the work using the typefaces we’ve always dreamed of. WEFT is not the tool right now to enable EOT usage. In fact it discourages it.

    Regardless of what security is implemented, the font file will have to be on the audience’s machine somewhere, even temporarily. ‘Defense in depth’ is a term used by web app security experts. It would seem that the question is how much depth will satisfy foundries and type designers, and what form that depth will take.

    As a designer, I can only speak for myself to say that if OTF and TTF were supported, regardless of how easy it was to steal the file, I would still pay as required by the EULA. I have a strong feeling the vast majority of my colleagues feel exactly the same.

    Share

  6. Quotation Marks & Texture

    Single quotation marks pattern.

    In the last entry, I stopped using double quotation marks and started using the single version. Some super-observant folks may have noticed but if you didn’t that’s also a good thing. Permit me to explain:

    The final test for running text is legibility, so failing to notice would mean the style was not imposing on the text. The texture was good. When they occur, stylistic interruptions provide me with food for thought. If the punctuation interrupts the meaning, it demands fresh scrutiny. Double quotation marks seemed to interrupt by emphasising too heavily. Emphasis is sometimes required, but to my mind, with my style of writing, it seemed to impose on the text, altering the meaning by changing the silent voice in my head reading the text.

    Legibility is subjective, and typographers can debate the nuances of style to achieve the best form until the end of time. However, context, typeface, and content are such varied beasts that trying to style them with one set of rules is unnatural, no matter how attractive it can seem. Whatever rules we follow, being consistent is a rule that’s truly universal. Knowing why we use a particular form is another. If we can’t justify a particular usage, the chances are we’ve probably not considered it enough.

    Context is important here. American English is the lingua franca of web design, from the properties of CSS, to the majority of text we read. The best-selling handbook of American writing style, The Elements of Style by Strunk and White, only provides examples with double quotation marks followed by singles for quotations within quotations:

    “This is a quotation with ‘another quotation’ inside it in the American style.”

    However, I’m British. I live and work in the UK. In the UK, double quotation marks are also used, but there’s also a tradition of single inverted commas being used as the primary, with double inverted commas contained within them as needed:

    ‘This is a quotation with “another quotation” inside it in the British style.’

    To my mind the latter imposes much less and suits me much better. I agree with book designer Jost Hochuli in Detail in Typography:

    ‘A more attractive appearance is achieved by using single quotation marks for the more frequently occurring quotations, and the double version for the less frequent occurrence of quotations within quotations.’

    Robert Bringhurst advises us to:

    ‘Consider the face as well as the text when deciding which convention to follow in marking quotations.’

    I agree with him but on the Web a face can change dramatically depending on the browser and operating system that’s rendering it. To my mind, we have to choose an optimal version — Safari in my case — and accept degradation after that. That’s also the case with other punctuation like spacing. I’ve just used hair spaces around the em dashes in the sentence before last, but you will see regular spaces unless you’re reading this using Safari — the only browser I know of that substitutes a hair space from the system fonts if one is not available from the specified face.

    Different languages also have different quotation marks like guillemets («»), and baseline inverted commas used as left quotation marks („); they are in common use in Germany, Russia, and Poland as Piotr Fedorczyk showed me recently. Punctuation within (or without) quotation marks is another topic altogether with a set of rules that depends on context and form. For example, American English puts commas inside. British English puts them outside depending on whether or not the comma (or full stop [period], or exclamation mark) is part of the quoted text.

    My view is, whatever style we choose, we should know why, and be prepared change it if necessary. Any rules we apply should aid legibility. Web typography is immature; the constraints and opportunities of the medium may take us down many different paths but the goal of legible, beautiful text is constant.

    Good typography in running text is subtle and ambient. It enhances the text without interrupting it. It delivers meaning with clarity. In books, speech is mainly quoted in single marks. It’s a light touch. The typography removes itself from the picture being painted in our minds, and by doing so, allows it to shine. I’d like to achieve the same kind of light touch, here. I doubt my text will shine, but at least the typography will not distract you from my thorny prose.

    Share