Hi,
I'm asking a couple of things -- is TT_NAME_ID_SAMPLE_TEXT specified anywhere? I'd expect it to contain something like "How quickly daft jumping zebras vex" but I wanted to check that was indeed the kind of thing it might show.
The seconds is really asking why so few fonts actually use this metadata item :) Would it be possible to add these in at package build time, as showing something like "Sample text" using Lohit-Punjabi.ttf doesn't make sense at all.
I'm also needing a much shorter text string for the icon (e.g. "Aa") but I guess keying on 'lang' is the best way to do this.
Thanks,
Richard.
Richard Hughes wrote:
Hi,
I'm asking a couple of things -- is TT_NAME_ID_SAMPLE_TEXT specified anywhere? I'd expect it to contain something like "How quickly daft jumping zebras vex" but I wanted to check that was indeed the kind of thing it might show.
Yes, it's in the OpenType specification:
https://www.microsoft.com/typography/otspec/name.htm
which just says:
"Sample text; This can be the font name, or any other text that the designer thinks is the best sample to display the font in."
The seconds is really asking why so few fonts actually use this metadata item :) Would it be possible to add these in at package build time, as showing something like "Sample text" using Lohit-Punjabi.ttf doesn't make sense at all.
I think the Latin-centric view is that any standard English pangram is reasonable, so they don't supply it. Non-Latin scripts would really benefit from some good sample text.
As the font packaging guidelines now require us to make font metadata corrections for licence-related strings, meaning you'll see more font packages using tools like ttname, it isn't a big leap to suggest that we also supply readsonable sample text, and suggest that upstream include it.
On 10 March 2014 13:50, Paul Flo Williams paul@frixxon.co.uk wrote:
I think the Latin-centric view is that any standard English pangram is reasonable, so they don't supply it.
Yes, that's fair enough.
Non-Latin scripts would really benefit from some good sample text.
Is there any precedent here? Like a Punjabi version of "How quickly daft jumping zebras vex" that shows off the majority of the glyphs?
As the font packaging guidelines now require us to make font metadata corrections for licence-related strings, meaning you'll see more font packages using tools like ttname, it isn't a big leap to suggest that we also supply readsonable sample text, and suggest that upstream include it.
That would be awesome. More fonts also using TT_NAME_ID_PREFERRED_FAMILY correctly would be great for my uses too.
Richard.
On 14-03-10 07:39 AM, Richard Hughes wrote:
Non-Latin scripts would really benefit from some good sample text.
Is there any precedent here? Like a Punjabi version of "How quickly daft jumping zebras vex" that shows off the majority of the glyphs?
pango_language_get_sample_string().
On 10 March 2014 17:50, Behdad Esfahbod behdad@behdad.org wrote:
pango_language_get_sample_string().
Looks good as a fallback, thanks. Would g_utf8_substring(value,0,2) give me sane results for a icon?
Richard.
On 14-03-10 01:52 PM, Richard Hughes wrote:
On 10 March 2014 17:50, Behdad Esfahbod behdad@behdad.org wrote:
pango_language_get_sample_string().
Looks good as a fallback, thanks.
By design pango_language_get_sample_string() is exactly what you want. If the implementation isn't, submit patches!
Would g_utf8_substring(value,0,2) give me sane results for a icon?
Don't think so. For that I suggest you get the sample char for all the scripts involved in the language (pango_language_get_scripts()):
https://docs.google.com/spreadsheet/ccc?key=0AqRLrRqNEKv-dG53NFlnbWg5TEp6ejV...
You can try upper/lower-casing the sample char and if the script is cased, use upper followed by lower.
Richard.
On 10 March 2014 21:06, Behdad Esfahbod behdad@behdad.org wrote:
https://docs.google.com/spreadsheet/ccc?key=0AqRLrRqNEKv-dG53NFlnbWg5TEp6ejV... You can try upper/lower-casing the sample char and if the script is cased, use upper followed by lower.
Okay, that looks awesome. Can I get that data from pango (e.g. pango_script_get_sample_char) or should I encode it into my program?
Richard.
On 14-03-11 04:17 AM, Richard Hughes wrote:
On 10 March 2014 21:06, Behdad Esfahbod behdad@behdad.org wrote:
https://docs.google.com/spreadsheet/ccc?key=0AqRLrRqNEKv-dG53NFlnbWg5TEp6ejV... You can try upper/lower-casing the sample char and if the script is cased, use upper followed by lower.
Okay, that looks awesome. Can I get that data from pango (e.g. pango_script_get_sample_char) or should I encode it into my program?
Commit to Pango please!
Richard.
On 11 March 2014 21:47, Behdad Esfahbod behdad@behdad.org wrote:
Okay, that looks awesome. Can I get that data from pango (e.g. pango_script_get_sample_char) or should I encode it into my program?
Commit to Pango please!
Okay, I've attached two different versions of incomplete patches for comments. I'd like to know how to encode the sample chars; all those 'if's makes for an unhappy compiler. switch/case might be slightly faster, or v2 just defines a static data table the size of all the entries in PangoScript (and add a private PANGO_SCRIPT_LAST) and does a direct lookup, although if the PANGO_SCRIPT_ defines ever get out of sync it'll be tricky to debug. Using the table looks sane to me, but it's just a pain to order all those enums :)
I've also chosen char * to return the sample char in, I figured this was more flexible than using gunichar and probably easier for the consumer to digest and use. Both patches are known incomplete and broken. Feedback please :)
Richard.
On 14-03-12 02:23 AM, Richard Hughes wrote:
On 11 March 2014 21:47, Behdad Esfahbod behdad@behdad.org wrote:
Okay, that looks awesome. Can I get that data from pango (e.g. pango_script_get_sample_char) or should I encode it into my program?
Commit to Pango please!
Okay, I've attached two different versions of incomplete patches for comments. I'd like to know how to encode the sample chars; all those 'if's makes for an unhappy compiler. switch/case might be slightly faster, or v2 just defines a static data table the size of all the entries in PangoScript (and add a private PANGO_SCRIPT_LAST) and does a direct lookup, although if the PANGO_SCRIPT_ defines ever get out of sync it'll be tricky to debug. Using the table looks sane to me, but it's just a pain to order all those enums :)
Table please.
I've also chosen char * to return the sample char in, I figured this was more flexible than using gunichar and probably easier for the consumer to digest and use. Both patches are known incomplete and broken. Feedback please :)
Nah. gunichar. It's one function call away from turning into UTF-8.
On 10 March 2014 23:20, Behdad Esfahbod behdad@behdad.org wrote:
On 14-03-10 07:39 AM, Richard Hughes wrote:
Non-Latin scripts would really benefit from some good sample text.
Is there any precedent here? Like a Punjabi version of "How quickly daft jumping zebras vex" that shows off the majority of the glyphs?
pango_language_get_sample_string().
This is what i used most of the time for generating sample text.
In lohit2 presently we are not adding "sample text" into Naming table but looks worth doing it. I will add it in coming releases of it.
Regards, Pravin Satpute
Le Mar 11 mars 2014 05:05, pravin.d.s@gmail.com a écrit :
On 10 March 2014 23:20, Behdad Esfahbod behdad@behdad.org wrote:
On 14-03-10 07:39 AM, Richard Hughes wrote:
Non-Latin scripts would really benefit from some good sample text.
Is there any precedent here? Like a Punjabi version of "How quickly daft jumping zebras vex" that shows off the majority of the glyphs?
pango_language_get_sample_string().
This is what i used most of the time for generating sample text.
In lohit2 presently we are not adding "sample text" into Naming table but looks worth doing it. I will add it in coming releases of it.
That works fine for simple single-script fonts. I'm doubtful we will find a satisfactory pre-filled text for big multiscript font.
The "correct" workflow that limits massive work duplication and auto-adapts to font changes would be for the app displaying the text to select the appropriate sample in a database like pango_language_get_sample_string depending on the locale the app user is currently interested in, and for pango_language_get_sample_string to base its sample on a query of coverage and opentype features of the font. I'm not sure if pango pangrams try to exhibit ligatures for example even though they are a very desirable feature from a font design point of view.
(and that gets us back to the way our desktop sucks and still uses input method switchers instead of a locale switcher that infers input method from desired locale and user preferences like windows does since around windows 95).
And of course once this has been nicely automated we can add a macro to pre-fill automatically TT_NAME_ID_SAMPLE_TEXT at font package build time so the font degrades gracefully in an environment where pango is not present (just like ttf-autohint can be used to "fix" fonts for fontconfig/freetype-less environments)
Regards,
-
Behdad Esfahbod -
Nicolas Mailhot -
Paul Flo Williams -
pravin.d.s＠gmail.com -
Richard Hughes