<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 25, 2018 at 7:40 AM, Richard Hughes <span dir="ltr"><<a href="mailto:hughsient@gmail.com" target="_blank">hughsient@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nathan, sorry for the delay.<br>
<br></blockquote><div><br></div><div>No worries!<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 29 April 2018 at 11:38, Nathan Willis <<a href="mailto:nwillis@glyphography.com" target="_blank">nwillis@glyphography.com</a>> wrote:<br>
> - <reserved_font_name><br>
<br>
Could these be <custom> tags? I don't think we have many<br>
component-type-specific tags in the format so far.<br></blockquote><div><br></div><div>Functionally, of course, the answer is yes. The docs page seems to discourage custom proliferation; perhaps I'm not clear where that line is.  <br><br>The docs also say that a vendor prefix needs to accompany <custom> tags; I'm not sure what that would be for a generalized font tag (i.e., you would want the tag to be the same for every font package, so there's not a traditional vendor).<br><br></div><div>I do realize that not a lot of other component types have engaged in much or any customization; although I sort of would expect <codec> to need a few additional bits.<br><br></div><div>Anyway, regardless, part of the trick here stems from the "fonts are software and are simultaneously a content element" dichotomy. The general upstream tags cover the "are software" dimension quite well; the goal is just to hit the major "content side" metadata points that somebody might want to filter/search on at the "do I want to install this" point in time. It still leaves other metadata for post-installation "which of my fonts works best here" questions.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> specimen<br>
<br>
Could that be a <url type="specimen"> perhaps?<br></blockquote><div><br></div><div>Can an <url> point to a local-within-the-package file?  Like <screenshot> does? If so, then absolutely....  (In fact, I may have described it as an <url> subtype in the original issue opened; I forget)<br><br>Being able to handle a file and a site would be nice. Because there is a mix, in the wild. Web-based specimen "micro-sites" are certainly on the rise, but the PDF version is still commonplace. Only a handful of Linux font packages include these at the moment (since they tend to get buried in /usr/share/doc/ and forgotten), but the SIL fonts are pretty consistent in this regard, as are a few other foundries/projects that maintain their own packages.<br><br></div><div>A specimen is one of those things that might be useful both in a pre-installation context and post-installation as well (i.e., with a large font library, you can't remember them all). <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> designer_name<br>
<br>
Is that much different to the <developer_name> tag?<br>
<span class="m_6564499256212769831m_-1019656972249582625HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>In practice, yes. They may be the same coincidentally; more likely so if it's a new font. <br><br>An easy example - the designer of Zapfino is Hermann Zapf, rather than whoever maintains the release. The fact that it's a Zapf font is more relevant than whichever corporate entity publishes the binary (and which can change over time).<br><br>In the docs, <developer_name> is defined as "the developers or project responsible for development of the project" ... which, well, the wording sounds a tad odd taken out of context like that, but seems to generally be used to reference the maintainer or the packager. <br><br></div><div>It's also quite common to use the designer name as metadata when doing a historical revival. I believe commercial font resellers use that to group "Garamonds" or whatever in their search results, since a Designer tag is defined in OpenType's `name` table. So this one would be analogous to the Artist Name in an MP3, while we've already got the Track Name from the name of the font. (Not sure what <developer_name> would correspond to ... studio, perhaps, but that's probably taking the metaphor too far).<br></div><br></div><br></div><div class="gmail_extra">Speaking of pre-installation info ... I hate to do this, but one other possible tag of value would be something that covers "design language". This is a (recent?) Microsoft invention in the OpenType `meta` table (described here: <a href="https://docs.microsoft.com/en-us/typography/opentype/spec/meta">https://docs.microsoft.com/en-us/typography/opentype/spec/meta</a> ) that indicates, essentially, what the primary language of the font is. MS uses it to choose what "quick brown fox" string to show in the Windows font picker. It might also be useful to users to search on in their package manager. <br><br>If the field is there in the font binary, it's more reliable than just scraping the Unicode block coverage — a lot of Chinese fonts include Latin, too, for example. And there can alsways be big differences between an Arabic font designed for the Arabic language and one designed for Persian, etc. Just a thought. I don't see anything in the generic tag set that would correspond ... may need more consideration....<br><br></div><div class="gmail_extra">Nate<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="m_6564499256212769831m_-1019656972249582625gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">nathan.p.willis<br><a href="mailto:nwillis@glyphography.com" target="_blank">nwillis@glyphography.com</a><a href="http://identi.ca/n8" target="_blank"></a></div></div>
</div></div>