Convert the logo's text to outlines - #13
Merged
Merged
Conversation
The mark positioned a live <text>riti</text> in High Tower Text, a font no visitor's browser has and which the SVG never embedded. Every visitor has been seeing that part of the logo in a substitute serif. It mattered more after the wordmark came out of the header and footer, because the mark became the only branding on the site. Both SVGs now carry the glyphs as a path, generated with fontTools from the genuine High Tower Text — same face the file always asked for, confirmed by PostScript name against both the SVG reference and the subset embedded in brand-source/logo-master.pdf. The font has no kern or GPOS table, so plain advance widths are what any renderer would have used. The text's total advance lands at x=583.57 against a viewBox 583.58 wide, which is the artboard edge the logo was drawn to. The font declaration is gone from both files. Nothing references a font now, so there is nothing left to resolve differently on someone else's machine. brand-source/README.md records why the master PDF could not be used: all ten of its streams are damaged by line-ending normalisation applied to a binary file. That is ambiguous rather than merely unknown — each surviving CRLF could have been CR, LF or CRLF — so it is not recoverable, and the font stream alone has 593 of them. Verified by rasterising old and new at 2x and diffing, on a machine that has the font so the old file renders as designed: every differing pixel falls inside the text's own bounding box, and not one is fully inked in one and fully blank in the other. The difference is antialiasing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The mark positioned a live
<text>riti</text>in High Tower Text — a font novisitor's browser has, and which the SVG never embedded. Every visitor has been
seeing that part of the logo in a substitute serif.
It matters more since #8 took the wordmark out of the header and footer: the
mark is now the only branding on the site.
What changed
Both SVGs carry the glyphs as a
<path>, generated with fontTools from thegenuine High Tower Text — the same face the file always asked for, confirmed by
PostScript name (
HighTowerText-Reg) against both the SVG's own reference andthe subset embedded in
brand-source/logo-master.pdf.The font has no
kernorGPOStable, so plain advance widths are exactly whatany renderer would use. A useful sanity check fell out of that: the text's total
advance lands at x = 583.57 against a 583.58-wide viewBox — the artboard
edge the logo was drawn to.
The
font-family/font-sizedeclaration is gone from both files. Nothingreferences a font now, so there is nothing left to resolve differently on
someone else's machine.
Why not the master PDF
brand-source/README.mdrecords this properly. In short: all ten of itscompressed streams are damaged by line-ending normalisation applied to a binary
file — the same damage that killed the PNGs removed in #11.
Diagnosed from a PNG in the same commit whose correct bytes are known:
A lone
0abecame0d 0a, a lone0dbecame0d 0a, an existing0d 0awasleft alone — and the file's
0aand0dcounts are exactly equal, confirmingfull CRLF normalisation. That is ambiguous, not merely unknown: each
surviving
0d 0acould have been0d,0aor0d 0a. The font stream alonecarries 593 of them. The PDF stays in the repo as a record; it is not shipped.
Verification
Rasterised old and new at 2x and diffed, on a machine that has the font
installed so the old file renders as designed:
Every differing pixel is inside the text's own bounding box — nothing outside
the glyphs changed — and not one is solid in one render and blank in the other.
The difference is antialiasing between text and path rasterisation.
Files grow 2.5kB → 5.1kB each. They are also the favicon, so that is the whole
cost.