Firefox 3.5 will be launching this summer (betas available now!) and will include support for downloading and using regular TrueType and OpenType fonts referenced from a style sheet:
https://developer.mozilla.org/en/CSS/@font-face
This is also supported in Safari 3.1 and later, and apparently by the latest Opera betas as well.
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
Internet Explorer afaik still only supports converted embedded (EOT) font files, which would require that we can either get our hands on an existing .eot version of each free font, or be able to generate one ourselves.
Note there's an old feature request with an .eot copy of a Tamil font: https://bugzilla.wikimedia.org/show_bug.cgi?id=2361
but we never had authorship info on the font or cross-browser support, since .eot is only supported by IE.
-- brion
On Mon, May 4, 2009 at 5:46 PM, Brion Vibber brion@wikimedia.org wrote:
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
Maybe you could enable TTF file uploads on Wikimedia projects for us?
On Tue, May 5, 2009 at 10:19 AM, Remember the dot rememberthedot@gmail.com wrote:
On Mon, May 4, 2009 at 5:46 PM, Brion Vibber brion@wikimedia.org wrote:
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
Maybe you could enable TTF file uploads on Wikimedia projects for us?
-- Remember the dot
That might cause issues and such since most creators want their readmes and such stored with them (and i've seen a few free ones with additonal rules against using in webpages as such so we would need to be aware of that as well), i think it might be better just to find the ones we want and ask the dev's to set them up for us.
On Tue, May 5, 2009 at 12:50 AM, K. Peachey p858snake@yahoo.com.au wrote:
That might cause issues and such since most creators want their readmes and such stored with them (and i've seen a few free ones with additonal rules against using in webpages as such so we would need to be aware of that as well),
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes or restrictions on type of use.
On Tue, May 5, 2009 at 3:59 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Would this also be a solution for the problem we have with supporting languages like Lingala ? The standard Latin fonts do not suffice.
Yes, if free fonts are available that are superior, and if users use a suitably modern browser. I believe the latest version of Safari would work, and so would the upcoming Firefox 3.5. If we have EOT support, all versions of Internet Explorer would work going back a long way.
Hoi, Do you agree with me that a font is superior when it has a better coverage? In my opinion the only thing that really counts is that we support the characters of the languages we support. All the rest is ballast preventing us from fulfilling our primary objective. Thanks, GerardM
2009/5/5 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Tue, May 5, 2009 at 12:50 AM, K. Peachey p858snake@yahoo.com.au wrote:
That might cause issues and such since most creators want their readmes and such stored with them (and i've seen a few free ones with additonal rules against using in webpages as such so we would need to be aware of that as well),
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes or restrictions on type of use.
On Tue, May 5, 2009 at 3:59 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Would this also be a solution for the problem we have with supporting languages like Lingala ? The standard Latin fonts do not suffice.
Yes, if free fonts are available that are superior, and if users use a suitably modern browser. I believe the latest version of Safari would work, and so would the upcoming Firefox 3.5. If we have EOT support, all versions of Internet Explorer would work going back a long way.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Aryeh Gregor wrote:
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes
An example (someone correct me if I'm wrong) is the SIL Open Font License.
Tim
I'd also offer my own MPH 2B Damase, although I'm not sure how it ranks in quality compared to other fonts these days. I created it several years ago and released it into the public domain.
http://en.wikipedia.org/wiki/Free_software_Unicode_fonts#MPH_2B_Damase
Mark
2009/5/11 Tim Larson larson@towncommons.com:
Aryeh Gregor wrote:
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes
An example (someone correct me if I'm wrong) is the SIL Open Font License.
Tim
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
El 5/11/09 4:09 PM, Mark Williamson escribió:
I'd also offer my own MPH 2B Damase, although I'm not sure how it ranks in quality compared to other fonts these days. I created it several years ago and released it into the public domain.
http://en.wikipedia.org/wiki/Free_software_Unicode_fonts#MPH_2B_Damase
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000.
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Mark
2009/5/11 Tim Larsonlarson@towncommons.com:
Aryeh Gregor wrote:
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes
An example (someone correct me if I'm wrong) is the SIL Open Font License.
Tim
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, One way of dealing with fonts is not only providing them for real time download but also for installation on the system. In this way we can provide the best possible service. Also we do need a proper font for the languages where the standard Latin fonts fail us !! Thanks, GerardM
2009/5/12 Brion Vibber brion@wikimedia.org
El 5/11/09 4:09 PM, Mark Williamson escribió:
I'd also offer my own MPH 2B Damase, although I'm not sure how it ranks in quality compared to other fonts these days. I created it several years ago and released it into the public domain.
http://en.wikipedia.org/wiki/Free_software_Unicode_fonts#MPH_2B_Damase
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000.
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Mark
2009/5/11 Tim Larsonlarson@towncommons.com:
Aryeh Gregor wrote:
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes
An example (someone correct me if I'm wrong) is the SIL Open Font
License.
Tim
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
that makes sense. In case of a language not covered by other fonts (if we have any?), I'd be happy to craft a single-script font for it. skype: node.ue
2009/5/11 Brion Vibber brion@wikimedia.org:
El 5/11/09 4:09 PM, Mark Williamson escribió:
I'd also offer my own MPH 2B Damase, although I'm not sure how it ranks in quality compared to other fonts these days. I created it several years ago and released it into the public domain.
http://en.wikipedia.org/wiki/Free_software_Unicode_fonts#MPH_2B_Damase
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000.
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Mark
2009/5/11 Tim Larsonlarson@towncommons.com:
Aryeh Gregor wrote:
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes
An example (someone correct me if I'm wrong) is the SIL Open Font License.
Tim
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber έγραψε:
El 5/11/09 4:09 PM, Mark Williamson escribió:
I'd also offer my own MPH 2B Damase, although I'm not sure how it ranks in quality compared to other fonts these days. I created it several years ago and released it into the public domain.
http://en.wikipedia.org/wiki/Free_software_Unicode_fonts#MPH_2B_Damase
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000.
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ...
Ariel
Mark
2009/5/11 Tim Larsonlarson@towncommons.com:
Aryeh Gregor wrote:
Those would, obviously, be forbidden to upload. As with any uploaded media, all uploaded fonts would need to be explicitly and irrevocably released under a free license, which means no requirements for readmes
An example (someone correct me if I'm wrong) is the SIL Open Font License.
Tim
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
El 5/11/09 5:04 PM, Ariel T. Glenn escribió:
Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000.
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ...
Hmmmm, well forcing a large automated font download on every reader's first visit probably isn't ideal. :) Short of crafting embedded type subsets for each page using just the required characters I'm not sure there's a good way to treat that case other than offering extra fonts for download.
-- brion
Brion Vibber schrieb:
El 5/11/09 5:04 PM, Ariel T. Glenn escribió:
Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000.
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ...
Hmmmm, well forcing a large automated font download on every reader's first visit probably isn't ideal. :) Short of crafting embedded type subsets for each page using just the required characters I'm not sure there's a good way to treat that case other than offering extra fonts for download.
-- brion
How about a small button somewhere? "download fonts now!". Could be hidden if no "special" chars are visible on the page.
-- daniel
I don't know about Safari, but Firefox 3.5 first renders the text and then downloads the fonts and rerenders, if I read this correctly: "When rendering a page using downloaded fonts, Firefox first renders using available fonts, then updates the display as downloadable fonts are retrieved. This allows the content to render quickly and refresh to match the intended look over time." https://developer.mozilla.org/en/CSS/@font-face
Best regards, Bence Damokos
2009/5/12 Daniel Kinzler daniel@brightbyte.de
Brion Vibber schrieb:
El 5/11/09 5:04 PM, Ariel T. Glenn escribió:
Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber
Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code
(eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc)
-- brion
Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ...
Hmmmm, well forcing a large automated font download on every reader's first visit probably isn't ideal. :) Short of crafting embedded type subsets for each page using just the required characters I'm not sure there's a good way to treat that case other than offering extra fonts for download.
-- brion
How about a small button somewhere? "download fonts now!". Could be hidden if no "special" chars are visible on the page.
-- daniel
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, May 12, 2009 at 4:16 AM, Bence Damokos bdamokos@gmail.com wrote:
I don't know about Safari, but Firefox 3.5 first renders the text and then downloads the fonts and rerenders, if I read this correctly:
Yes, that's what I understand as well. It was discussed on www-style just a little while ago:
http://lists.w3.org/Archives/Public/www-style/2009May/0036.html
Safari avoids Firefox's behavior to avoid re-rendering text, on the same principle as browsers these days don't start layout until they've got all CSS (to avoid FOUC). See also:
On Mon, May 11, 2009 at 8:04 PM, Ariel T. Glenn ariel@wikimedia.org wrote:
Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ...
It's not a good idea, however you slice it, for text on the page to not render while a multimegabyte font file downloads on the first page view. As far as I know, this is exactly what happens in Safari right now. If that's correct (I haven't tested), little squares for some users on some pages are far preferable. Even if an interim font does render while the web font downloads, it's still not a good use of our viewers' bandwidth.
On Mon, May 11, 2009 at 8:21 PM, Brion Vibber brion@wikimedia.org wrote:
El 5/11/09 5:04 PM, Ariel T. Glenn escribió:
I can see your Spanish practice going on right now. :D
El 5/11/09 5:27 PM, Aryeh Gregor escribió:
On Mon, May 11, 2009 at 8:04 PM, Ariel T. Glennariel@wikimedia.org wrote:
Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ...
It's not a good idea, however you slice it, for text on the page to not render while a multimegabyte font file downloads on the first page view. As far as I know, this is exactly what happens in Safari right now. If that's correct (I haven't tested), little squares for some users on some pages are far preferable. Even if an interim font does render while the web font downloads, it's still not a good use of our viewers' bandwidth.
Yup... Let's arbitrarily throw around size targets like: <100k good, <50k best, <20k miraculous. Primary target for scripts with major accessibility problems, where the download tax is outweighed by the improved reach.
On Mon, May 11, 2009 at 8:21 PM, Brion Vibberbrion@wikimedia.org wrote:
El 5/11/09 5:04 PM, Ariel T. Glenn escribió:
I can see your Spanish practice going on right now. :D
:D
-- brion
On Mon, 4 May 2009, Brion Vibber wrote:
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
It sounds like a good way to provide the STIX fonts for rendering MathML as well, since currently one has to point users to a font help page just like that, and hope they don't give up before they get to installing the fonts and seeing the nice-looking equations.
Hoi, Would this also be a solution for the problem we have with supporting languages like Lingala ? The standard Latin fonts do not suffice. Thanks, GerardM
2009/5/5 Brion Vibber brion@wikimedia.org
Firefox 3.5 will be launching this summer (betas available now!) and will include support for downloading and using regular TrueType and OpenType fonts referenced from a style sheet:
https://developer.mozilla.org/en/CSS/@font-face
This is also supported in Safari 3.1 and later, and apparently by the latest Opera betas as well.
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
Internet Explorer afaik still only supports converted embedded (EOT) font files, which would require that we can either get our hands on an existing .eot version of each free font, or be able to generate one ourselves.
Note there's an old feature request with an .eot copy of a Tamil font: https://bugzilla.wikimedia.org/show_bug.cgi?id=2361
but we never had authorship info on the font or cross-browser support, since .eot is only supported by IE.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Brion Vibber wrote:
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
On Tue, May 5, 2009 at 9:47 AM, Nikola Smolenski smolensk@eunet.yu wrote:
Brion Vibber wrote:
It might be helpful for some language wikis to link in a free font this way, when standard fonts supporting their script are often unavailable. Right now on such sites there tends to be a little English link at the top such as 'font help' leading to a page like this telling you how to download and install a font: http://ta.wikipedia.org/wiki/Project:Font_help
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
This should be pushed to the client end I think because even the page uses
a rare character, the decision should be for the browser to load the font and not for mediaWiki to push it. Some front end js can do the task well.
On Tue, May 5, 2009 at 9:47 AM, Nikola Smolenski smolensk@eunet.yu wrote:
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
The problem with this is that it means the characters may be displayed in a different font even if the default font actually contains them, which is needlessly ugly. We can't say "Use this font, but only if the font that would otherwise be used doesn't contain character X". It's an okay tradeoff for languages where very few computers can read them otherwise by default, but it needs to be used with care.
On Tue, May 5, 2009 at 9:42 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Do you agree with me that a font is superior when it has a better coverage?
The user should be able to use whatever font they like. Wikipedia currently does not specify a default font; the user's default is used. This will often be the default system sans-serif font, which will blend in nicely. Forcing a different font should only be done with excellent reason (such as if text would otherwise show up as gibberish on nearly all computers).
Hoi, Sans serif is a font family. It does not mean that the font itself contains the characters to show a language properly. As it is, I am not aware that Lingala is supported by any modern browser in the configuration we use our fonts in. Thanks, Gerard
2009/5/5 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Tue, May 5, 2009 at 9:47 AM, Nikola Smolenski smolensk@eunet.yu wrote:
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
The problem with this is that it means the characters may be displayed in a different font even if the default font actually contains them, which is needlessly ugly. We can't say "Use this font, but only if the font that would otherwise be used doesn't contain character X". It's an okay tradeoff for languages where very few computers can read them otherwise by default, but it needs to be used with care.
On Tue, May 5, 2009 at 9:42 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Do you agree with me that a font is superior when it has a better
coverage?
The user should be able to use whatever font they like. Wikipedia currently does not specify a default font; the user's default is used. This will often be the default system sans-serif font, which will blend in nicely. Forcing a different font should only be done with excellent reason (such as if text would otherwise show up as gibberish on nearly all computers).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I've formally requested that TTF file uploads be enabled at https://bugzilla.wikimedia.org/show_bug.cgi?id=18692
El 5/6/09 12:02 PM, Remember the dot escribió:
I've formally requested that TTF file uploads be enabled at https://bugzilla.wikimedia.org/show_bug.cgi?id=18692
Probably no point to that, since fonts are restricted by the same-origin rule (at least in Firefox). They'll need to be hosted along with the web servers, or else we'd have to jump through some hoops for magic headers to support cross-site includes, which may or may not be a good idea.
-- brion
On Wed, May 6, 2009 at 10:18 AM, Brion Vibber brion@wikimedia.org wrote:
El 5/6/09 12:02 PM, Remember the dot escribió:
I've formally requested that TTF file uploads be enabled at https://bugzilla.wikimedia.org/show_bug.cgi?id=18692
Probably no point to that, since fonts are restricted by the same-origin rule (at least in Firefox). They'll need to be hosted along with the web servers, or else we'd have to jump through some hoops for magic headers to support cross-site includes, which may or may not be a good idea.
Good point. Personally, I'd use the magic headers. It looks like "Access-Control-Allow-Origin: http://upload.wikimedia.org" would do the trick.
On Wed, May 6, 2009 at 2:43 PM, Remember the dot rememberthedot@gmail.com wrote:
Good point. Personally, I'd use the magic headers. It looks like "Access-Control-Allow-Origin: http://upload.wikimedia.org" would do the trick.
Ah shoot, I'm sorry. That's incorrect, instead we'd have to list every Wikimedia server in upload.wikimedia.org's Access-Control-Allow-Origin headers. That wouldn't work very well. You're right: we'd have to host the fonts with the web servers themselves.
We could also use "Access-Control-Allow-Origin: *" if hotlinking isn't a concern. Because we don't worry about hotlinking with other file types, this might be the best option.
-- Remember the dot http://en.wikipedia.org/wiki/User:Remember_the_dot
El 5/6/09 1:59 PM, Remember the dot escribió:
We could also use "Access-Control-Allow-Origin: *" if hotlinking isn't a concern. Because we don't worry about hotlinking with other file types, this might be the best option.
More fun background on this here: https://developer.mozilla.org/en/HTTP_access_control
Probably safe. Probably. :)
-- brion
Aryeh Gregor wrote:
On Tue, May 5, 2009 at 9:47 AM, Nikola Smolenski smolensk@eunet.yu wrote:
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
The problem with this is that it means the characters may be displayed in a different font even if the default font actually contains them, which is needlessly ugly. We can't say "Use this font, but only if the font that would otherwise be used doesn't contain character X".
Or can we? I will experiment a bit, but I guess something like this would work:
@font-face { font-family: glagolitic; src: url("http://upload.wikimedia.org/fonts/glagolitic.ttf"); }
body { font-family: sans-serif, glagolitic }
If default sans-serif font doesn't have Glagolitic characters, Firefox will use any available font that has them, that should include glagolitic.ttf .
On Wed, May 6, 2009 at 3:08 AM, Nikola Smolenski smolensk@eunet.yu wrote:
body { font-family: sans-serif, glagolitic }
I don't think this actually works. sans-serif means "pick the characters from any available sans-serif font". Anything after it should therefore be ignored. I think. I could be wrong.
CSS2.1 seems vague on whether you should pick fonts on a character-by-character basis, or just pick the first font available and use it for everything. Firefox usually tries fallback, but last I checked, IE doesn't. (Last I checked was probably IE6, though.)
If default sans-serif font doesn't have Glagolitic characters, Firefox will use any available font that has them, that should include glagolitic.ttf .
Does that actually work, though, in the betas?
Hoi, What would you describe as a rare font.. There are many articles in languages like Georgian, Kannada, Telugu or Dhihevi. There may be MANY interwiki links to the projects in those languages.. So my question is what makes them rare in your book ? Only one reference on a page ? What does that do for Japanese or Korean ?? Thanks, GerardM
2009/5/7 Platonides Platonides@gmail.com
Nikola Smolenski wrote:
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
Note that one interwiki in a rare font shouldn't produce a font download.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
What I believe he's saying is that if a script is only used for a single interwiki link in a page, we shouldn't call a font for it.
If you try to view articles in that language, on the other hand, it will of course be reasonable to call a font.
Some computers would be downloading fonts for every page that had Georgian, Armenian, or Indic interwikis, I would imagine that would use a lot of resources far beyond what is necessary.
Japanese and Korean are likely to be supported on almost every computer used by people who speak those languages so there's very little dilemma there; for Indic languages (like Telugu for example) or Divehi this is often not the case.
Mark
2009/5/8 Gerard Meijssen gerard.meijssen@gmail.com:
Hoi, What would you describe as a rare font.. There are many articles in languages like Georgian, Kannada, Telugu or Dhihevi. There may be MANY interwiki links to the projects in those languages.. So my question is what makes them rare in your book ? Only one reference on a page ? What does that do for Japanese or Korean ?? Thanks, GerardM
2009/5/7 Platonides Platonides@gmail.com
Nikola Smolenski wrote:
Even more helpful: MediaWiki could determine if a page uses a rare character upon save and link to appropriate fonts.
Note that one interwiki in a rare font shouldn't produce a font download.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, May 8, 2009 at 6:55 AM, Mark Williamson node.ue@gmail.com wrote:
What I believe he's saying is that if a script is only used for a single interwiki link in a page, we shouldn't call a font for it.
If you try to view articles in that language, on the other hand, it will of course be reasonable to call a font.
Some computers would be downloading fonts for every page that had Georgian, Armenian, or Indic interwikis, I would imagine that would use a lot of resources far beyond what is necessary.
WebKit apparently blocks text rendering until all custom fonts have been downloaded. I'm not sure if it just avoids rendering the text in the custom font, or all text on the page -- if the latter, then we'd have to be *very* sparing with custom fonts. (Gecko has a FOUC effect instead: it renders with the fonts it has, and then re-renders when it gets the right ones. So that's less of an issue, although we don't want people downloading 20 fonts on every main page view in any event.)
On Fri, May 8, 2009 at 11:05 AM, Tei oscar.vives@gmail.com wrote:
what license will use these downloadable fonts ?
Any fonts hosted by Wikimedia would presumably need to be released under an OSI-approved license, like all other content.
El 5/8/09 9:32 PM, Aryeh Gregor escribió:
On Fri, May 8, 2009 at 11:05 AM, Teioscar.vives@gmail.com wrote:
what license will use these downloadable fonts ?
Any fonts hosted by Wikimedia would presumably need to be released under an OSI-approved license, like all other content.
Yup. Free fonts with known sources only please. :)
-- brion
wikitech-l@lists.wikimedia.org