Re: [OpenFontLibrary] Libre Graphics Meeting 2014: Call For Paper
Hi, Dave! I just submitted a proposal for a 20 minute presentation for the upcoming Libre Graphics Meeting on the development of my Tai Tham font. I think there is a fairly interesting story that is being driven by the synergies of unmet needs and unfolding at the intersection of technology and design. There is a lot of interest in Southeast Asia and internationally to preserve and make palm leaf manuscripts available to scholars and the wider public online. Collaborations between organizations in the West and in Southeast Asia are already making palm leaf manuscripts available online (e.g.: l'École française d'Extrême-Orient (EFEO) in France and Sirindhorn Anthropology Centre (SAC) in Bangkok; and also the National Library of Laos along with the University of Passau and the Staatsbibliothek zu Berlin Preußischer Kulturbesitz in Germany) --- but at the same time high-quality Unicode-based Tai Tham fonts and input methods are not yet available. Of course I'm working on a Tai Tham font; and Theppitak Karoonboonyanan in Thailand is working on Tai Tham input methods that will automatically perform normalisation of the input sequence (normalisation issues could easily be a whole talk by itself!). On my end, working on a Tai Tham font, collaboration with the HarfBuzz OpenType layout engine community is proving critical to getting things done. I don't know if the LibreGraphics folks are interested, but just thought I'd let you know. I'm now making good progress on some of the technical OpenType hurdles in Hariphunchai. Hopefully I will be submitting an invoice to Google quite soon :-) Best Wishes -- Ed On Tue, Nov 26, 2013 at 2:28 PM, Dave Crossland d...@lab6.com wrote: Hi! http://libregraphicsmeeting.org/2014/?p=199 The Call for Participation has now been published! For this year we are especially interested in presentations that showcase how the gap between technical and design development can be bridged. We are looking for: In-depth presentations on Libre Graphics technologies Showcases of excellent work made using Libre Graphics tools New projects in this area to meet the wider community Reports, use-cases, best practices New emerging media; breaking free from analog constraints Well articulated ideas for future approaches, tools and standards Available formats are: Lightning talk (10 minutes, selected at the event unconference style) Presentations (20 minutes extendable to 40 minutes) Entry for State of the Libre Graphics Union (1-2 slides) Workshops (2 hours or more) Birds Of a Feather (BOF), discussion meetings or Hackathons (2 hrs or more) The 2014 Libre Graphics Meeting will be held April 2 – 5 in Leipzig, Germany at Universität Leipzig. Deadline for submissions: 15 January 2014 Selection notifications by: 25 January 2014 at the latest. http://libregraphicsmeeting.org/2014/?page_id=165 The Libre Graphics Meeting 2014 will take place 2. – 5. April 2014 in Leipzig, Germany. This yearly event is an occasion for projects and individual contributors/artists from all over the world to work together, to share experiences and to hear about new ideas. By Libre Graphics we mean Free, Libre and Open Source tools for design, illustration, photography, typography, art, graphics, page layout, publishing, cartography, animation, video, interactive media, generative graphics and visual live-coding. The Libre Graphics Meeting is not just about software, but extends to standards, file formats and actual use of these in creative work. We are looking for: In-depth presentations on Libre Graphics technologies Showcases of excellent work made using Libre Graphics tools New projects in this area to meet the wider community Reports, use-cases, best practices New emerging media; breaking free from analog constraints Well articulated ideas for future approaches, tools and standards Available formats (including questions): Lightning talk (10 minutes, selected at the event unconference style) Presentations (20 minutes extendable to 40 minutes) Entry for State of the Libre Graphics Union (1-2 slides) Workshops (2 hours or more) Birds Of a Feather (BOF), discussion meetings or Hackathons (2 hrs or more) State of the Libre Graphics Union: We will kick off this year’s event with a joint session that sums up all things that have happened in our wide landscape over the last year. Instead of slots in the schedule for general updates on each and every libre graphics project, we invite you to submit a maximum of two slides, show-casing new abilities and/or text enumerating the leaps forward that your project made. Special focus: For the 2014 edition of LGM, we are specifically interested in presentations that showcase how the gap between technical and design development can be bridged. We are looking for contributions on computational and generative media; examples of projects where design decisions and experimentation is done directly with logic
Re: [OpenFontLibrary] Inkscape-FontForge Extension
Hi, Dave! Thanks for posting - this looks very interesting. Usually around the holidays I can find a bit more time to work on special projects, and so I am now gearing up and excited to get back to work on Hariphunchai. Maybe I will try out this new Fontforge extension in the process! Best Wishes - Ed On Mon, Nov 14, 2011 at 1:02 PM, Dave Crossland d...@lab6.com wrote: Hi Felipe has been working on a simple Inkscape extension to make it easier to go from Inkscape to FontForge: http://understandingfonts.com/blog/2011/11/typography-extensions-in-inkscape-0-49/ Your suggestions about what to do next for this project are welcome :-) -- Cheers Dave
[OpenFontLibrary] Fwd: Using Javascript to Detect Script Support in a Browser
I sent the following to the Unicode mailing list. People on this list might have some ideas too, so I am forwarding it here as well: -- Forwarded message -- From: Ed Trager ed.tra...@gmail.com Date: Tue, Jun 15, 2010 at 2:13 PM Subject: Using Javascript to Detect Script Support in a Browser To: Unicode Mailing List unic...@unicode.org Hi Unicoders, Suppose that we write Unicode text in a web page that we create. We are worried that our viewers' computers lack a font for proper display of the script in which our text is written. Obviously it will not be good if our users only see square boxes or question marks instead of the text that we want them to be able to see and read: □ ... = Bad! :-( We want a solution to this problem. Until very recently, apparently the best we could do was to warn the user of the possibility of unrenderable text. For example Wikipedia, on pages related to Indic languages, says: “This article contains Indic text. Without proper rendering support, you may see question marks or boxes, misplaced vowels or missing conjuncts instead of Indic text.” But now that “good” browsers support @font-face, we can envision a better solution: If the browser does not have a font for rendering a specific script, we can dynamically supply one. I have written some simple Javascript to detect whether a user's web browser can display Unicode text in a specific ISO 15924 script. Here's how it works, using Javascript: * Create two divs on the page but set the CSS opacity to zero so the user doesn't see them. * In one div, place a relatively narrow letter from the target script. For example, for Latin one might choose i. * In the other div, place a relatively wider letter from the target script. For Latin, w is an obvious choice. * If the width of the two divs is identical, then the letters were rendered as square boxes or question marks. * Otherwise, if the widths differ, then the browser has found a system font capable of rendering the text. In the case of a negative result where the widths are the same, we can then dynamically add an @font-face rule to the page to download an appropriate font. I have an experimental web application that already does exactly this to support Tai Tham (Lanna) script. As Lanna is a fairly recent addition to Unicode, only a very few people will have a Lanna font available on their machines. Astute unicoders on this list will probably already have recognized one or more shortcomings of this method. This method works perfectly for most scripts, but of course it fails for monospaced scripts like Chinese, Japanese, Korean, Yi, and possibly some others like Phags Pa. For monospaced scripts, I tried doing this: * In the first div put U+FFFE. Every browser I tested rendered U+FFFE as a square box. * In the second div put a representative character from the script, such as 中 or 文 for Chinese. In theory, the U+FFFE will always be rendered as a box with a fixed width, and one would expect that there is a fairly good probability that the fixed width of any Chinese font on the machine will not be exactly the same as the width of the fallback square box. But in practice, based on my tests, this does not work. One problem is that Firefox's fallback square boxes contain the Unicode code point hex digits -- and these fallback square boxes can actually be of different widths depending on the hex codes contained therein. Also it might just happen that the fixed width of the Chinese glyph is exactly the same width as that of the fallback box used to render the U+FFFE. It would be very nice to come up with a reliable solution for scripts that are traditionally monospaced. Does anyone have any brilliant ideas? - Ed Trager
Re: [OpenFontLibrary] Google Font Directory
I also have thought that by hosting the fonts, they will probably start tracking font popularity, if nothing else. It would be pretty interesting, both for consumers of fonts and font authors, to have actual data on the relative popularity of various fonts. On Sun, May 23, 2010 at 1:44 PM, Garrick Van Buren garr...@kernest.com wrote: I agree there are business reasons for Google hosting fonts, but I'm not as confident about tying them to better targeted advertising. I think it's more about them reducing licensing fees on their end for their own apps (think Google Docs etc). http://garrickvanburen.com/archive/google-offering-droid-for-font-face-use Is this helpful? --- Garrick Van Buren 612 325 9110 garr...@kernest.com --- Kernest.com Free, Subscription, and Web Native fonts. --- On May 23, 2010, at 12:09 PM, Liam R E Quin wrote: On Sun, 2010-05-23 at 10:58 +0200, Schrijver wrote: nice. Yet; if they’re open to font contributions, why don’t they just mirror the catalogue of OFLBv2? By encouraging people to use an API, Google makes sure most people will refer to the fonts on their site, and this lets them add a cookie, and track visitors to more Web sites, helping them to learn more about people, and present them with better-targeted advertising. So there's a fairly clear (as I see it at least) business reason for them to do this. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org
Re: [OpenFontLibrary] Kernest’s Web Font Serving En gine – Fontue – Now Open Source
On Wed, Apr 21, 2010 at 8:15 PM, Barry Schwartz chemoelect...@chemoelectric.org wrote: Nicolas Spalinger nicolas_spalin...@sil.org skribis: I like the way you're not hiding the origin, license and other metadata of the libre/open fonts you include in your catalog (Ahem unlike others apparently: http://readableweb.com/typekit-and-copyright-fraud/ but they promised they will work on clarifying it..) More like blog fraud, if you ask me. :) But TypeKit did make the mistake of writing language that sounds legal, rather than English. (The ISC license is the only I can think of that is written in English, and for that you have to disregard the disclaimer, which is written in Alpha Centauran.) TypeKit embeds my fonts, as a service to others; they should embed the copyright string with the font, but it doesn't really matter, because I do not require attribution when someone embeds my fonts. Some _do_ require attribution for embedding (Jos Buivenga, for one), but I'm not sure it's TypeKit who needs to do the attributing; rather the website using the font. Personally, I think requiring attribution for the use of a text font is somewhat like requiring a painter to follow the signature with a note about what brand of paint, brushes, palettes, and easles were used. People who are really interested in fonts often will know already who the font author is, and will make the effort to find out if they like the font. Other people don't care as much and so will most likely not pay much attention to the attribution even if it is present. So in the end analysis, it may not make that much difference whether attribution is given or not ...
Re: [OpenFontLibrary] OpenID = Let the spam roll in like crazy.
Hi, Dave and Everyone, Spammers have become a seriously problem for web sites of all stripes and sizes. Note especially that the big sites like Google, Yahoo, MySpace, and Facebook have tons of spam accounts because they are, by definition, sites that allow everyone to sign up for an account. Those sites have millions of valid users -- and a presumably a proportionate fraction of spam accounts too. So this just means we will have to carefully consider how to address this issue. As far as I remember, the file upload code that I had developed and handed over to Ben for the OFLB beta does some checks to see if the font files included in a zip package are really font files (as opposed to trojan files that happened to be named with .TTF or the like). In light of Fontfreedom's comment, it will be worthwhile to revisit that code and see whether additional rigor and vigilance is required before going live. This is certainly an important part of what we can do to avoid spammer activity. The fact that OpenId is attacked by spammers does not necessarily mean that OpenId is at fault or an inappropriate choice. I think most of us will agree that it is still worthwhile to use Google or Facebook services even though those sites suffer from orders of magnitude more spam accounts than smaller sites. So I'm personally not yet ready to discount the possible value of using OpenId as a login service. A further investigation of the merits --or lack thereof-- is required. Best - Ed On Wed, Mar 10, 2010 at 4:49 AM, Dave Crossland d...@lab6.com wrote: On 9 March 2010 21:57, fontfree...@aol.com wrote: OpenID = Let the spam roll in like crazy. I've used it on my sites b4...I do drupal dev, and that's just it... Okay cool. How do you block spam?
Re: [OpenFontLibrary] Phone conversation with Ed Trager
Hi, everyone, On Mon, Mar 8, 2010 at 9:18 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 3/8/10, Dave Crossland wrote: Ed thinks about replacing ccHost with a custom webapp. To set the record straight, like many of you I've been wondering all these months what the holdup was with the cchost prototype? I contributed a bunch of code to that, and naturally would like to see the fruits of my labor --as well as the fruits of the labors of so many others-- realized. So this puzzlement was really the genesis of my conversation with Dave. And my suspicion going into the conversation was: is cchost part of the problem? Also, I was thinking is cchost the right platform for what we want to do? So, I was thinking, let's explore an alternative pathway: What do we want to do? Write that down as an outline. If the most important parts of what we want to do are simple and straightforward, then let's just write a custom web app to do it. But note that such a custom web app would still capitalize on stuff that we already collectively know how to do well anyway: i.e., PHP with MySQL and, on the Javascript side, jQuery. Also, for the login and security aspects I was thinking about using OpenId (OpenId.net). Also, I've been working on a bunch of jQuery-based code for web applications in my day job, and have also been thinking of using OpenId for some web apps in my day job. So I was visualizing how I might be able to apply and reuse some of what I have been doing in my paid work toward the OFLB project. Now if Aiki is a really good solution to the problems, then I won't argue against it. But is it a really good solution or not? I don't yet know, because I only heard about it yesterday when talking with Dave, and I don't yet know anything else about it. In the end, I only argue for using the right tool(s) for the job. So that could be Aiki or something else. But it looks more and more like cchost was really not the right tool, and from what I understand, modifying and customizing cchost was very laborious and frought with bugs. Ed suggests just talking about OFLB v2 again for the 4th time at LGM? Umm ... I wasn't even at LGM in the last couple of years ... Ed is offering to cut the code for this, so, don't be mean to him. :-) What's the point of being mean when I can be nasty? :) It's OK, Alexandre, I'll take it if you agree to let me dish it out too :-) Alexandre - Ed
Re: [OpenFontLibrary] An index for OFL fonts
IIRC Dave's presentation of the features of the OFLB at the last LGM had a nice php frontend with jquery and fontaine magic underneath to report interactively on the coverage of a font, a font covering part of the Turkish writing systems was used as an example I think. That was something I wrote with the intention of it eventually being integrated into OFLB. More recently I have been thinking that it would be useful as a stand-alone service too. I plan to add it to my unifont.org site as soon as I have time to do so. Unfortunately, I've been uber busy the last few weeks with no down time at all, so this too will have to wait a bit ... -- Ed
Re: [OpenFontLibrary] OneClickOrgs beta - our environment is now ready
Hi, Dave, That sounds good. I would be happy to be on the board. LGM will be in Brussels: I'll have to work on things to make sure I can get there, but that would certainly be fun. Best - Ed On Thu, Dec 3, 2009 at 3:51 AM, Dave Crossland d...@lab6.com wrote: Hi! Okay, I have been in contact with the good people at http://www.oneclickor.gs/ about getting a light weight legal structure set up for OFLB, and they are ready to take us on :-) To do this I need 5 people willing to be 'core members' who will sit on the board of the group, and who will be at the LGM2010 in May next year to have a face to face meeting. I'm guessing this would be: Ben Weiner Ed Trager Nicolas Spalinger Jon Phillips Alexandre Prokoudine When we agree on this, I'll put in the names and email details of the founding members of the legal organisation, an agenda will be created that allows for a meeting to occur in the real world. Once that meeting has been held on the agreed date, I will then go back to the website and finish off the founding of the official organisation. -- Regards, Dave
Re: [OpenFontLibrary] Fontaine
Hi, Dwayne, OK, I added Venda (South Africa) orthography to Fontaine: == svn ci -m Added Venda (South Africa) and Igbo Onwu (Nigeria) orthographies Sendingtrunk/src/FontFace.cpp Adding trunk/src/orthographies/IgboOnwu.h Adding trunk/src/orthographies/Venda.h Sendingtrunk/src/orthographies/orthographies.h Transmitting file data Committed revision 34. == While I was at it, I added Igbo Onwu (Nigeria) to Fontaine also. I've been working on a Javascript-based Igbo keyboard, so that was easy to do -- Maybe I will make a Venda keyboard next? The idea of adding a --orthography=XXX,YYY,ZZZ option is a good one. I needed just that functionality yesterday in fact! Of course there already exist the fontconfig tools, ie.. fc-list -- but I don't suppose that Fontconfig includes Venda or other African orthographies? You could submit patches to fontconfig though. As for Fontaine, adding orthographies that are specific to individual languages (such as Venda and Igbo) as opposed to larger orthography groups (such as my PanAfrican group in Fontaine) does raise issues about the future design of Fontaine that I have not yet considered fully : The main issue is not to create endlessly long reports when those are not needed. I'll have to think about this more ... Best - Ed On Fri, Aug 28, 2009 at 9:20 AM, Dave Crosslandd...@lab6.com wrote: Hi Dwayne! 2009/8/28 Dwayne Bailey dwa...@translate.org.za: Fontaine is a Wonderful Tool(TM) :) Thanks! Its all Ed Trager's hard work though! I expect you'll know his website, unifont.org Ed, I met Dwayne at the Open Translation Tools 2007 conference in Croatia and he works at www.translate.org.za who are famous for http://en.wikipedia.org/wiki/Pootle among other good works to help FOSS in South Africa :-) I just completed a build and added Venda support. It works great and I've been checking South African coverage for free fonts. Wonderful - I hope you can submit your patch to Ed :-) Do I send feature requests to you? Ed, is there a publish roadmap document that users can comment/add to? :-) While the output is great I mostly want to be able to check that a font has support for South African languages. So the ability to limit the request to only report coverage for certain orthographies e.g. --orthography='Basic Latin;Venda;Afrikaans' That way I just see what I need to evaluate quickly. That seems like a good feature to add :-) Did I say this was a great tool! When you said sponsor is that through your font business? Essentially Ed's development has been on a volunteer basis, and I've been giving him donations from my business' expense account with money I earned doing systems administration work. I haven't yet got a business running around fonts, and I have some more family stuff to take care of the next few months But I do plan to hit the font stuff once I am free :-) Hope you are well and enjoying the winter/summer :-) Dave
Re: [OpenFontLibrary] Contribute logos for permissive font licenses on OFLBv2
Hi, all, For what it is worth, here's my 2 cents opinion: = I like having the full acronym as text next to the logo. In this I believe I concur with Dave and Ben. = Because I liked the MIT logo with the dinosaur, I made up some quick-and-dirty samples for OFL and GPL that would match the MIT logo. = I created color, grayscale and black white alternates just to see what they would look like. My conclusions?: = I actually kind of like the color column. = The cartoonish version of the GNU head would need to have a few adjustments for better clarity at this small size. I've decided I really don't like the other GNU head (on the far right in the blackwhite column. = The dinosaur could also perhaps be put in color -- not sure what color would be appropriate? = The samples would need to be at the 71x30 size -- not sure if that would work or not? Image attached Best - Ed On Fri, Jul 31, 2009 at 6:57 AM, Ben Weinerb...@readingtype.org.uk wrote: Hi Dave Crossland wrote: So do we have consensus on these icons with the full acronym as text next to it? I support the idea. Only query I have remaining is if we keep all 3 as black or have different colors? Yes, what happened to the colour idea? Was it seen as unnecessary? Ed's orthography icons are also coloured so perhaps it is wise to avoid on the license icons ... Ben -- Ben Weiner | http://readingtype.org.uk/about/contact.html attachment: SampleLicenseLogos.png
[OpenFontLibrary] Updated Fontaine SVN Revision 30
Hi, everyone, As a result of recent discussions on this list in the last few days, I decided to investigate Fontaine's handling and support of different font file formats in a more systematic fashion. In addition to filling in some gaps in support for Type1 Postscript fonts, I also did extensive testing on Apple OS X for the first time. The result of this work is that Fontaine SVN revision 30 is now available with the following improvements: (1) Improved support for Type1 (Postscript) fonts. (2) Extensively tested to verify that Fontaine correctly handles the following font file types and formats: TrueType (TTF, OTF, CFF, Apple dfont and AppleDouble-encoded TrueType/OpenType), Type1 (.pfa, .pfb), and X11 bitmap (.pcf.gz). (3) Added XFree86 license detection. (4) Revised X11/MIT and IPA license detection. (5) Added a small addition to one of the CMakeLists.txt (6) Improved handling of license URLs === Getting Fontaine === Fontaine is now a project on sourceforge: http://sourceforge.net/projects/fontaine/ Anyone may obtain the source code for Fontaine from the SVN repository: svn co https://fontaine.svn.sourceforge.net/svnroot/fontaine === Building Fontaine === Fontaine uses the cross-platform cmake-based build system: cd fontaine/trunk cmake . make su -c make install or sudo make install
Re: [OpenFontLibrary] Updated Fontaine SVN Revision 30
Oops, I forgot to add it ... OK, it is there now (SVN revision 31). Sorry about that, but thanks for alerting me! Best - Ed On Fri, Jul 17, 2009 at 3:09 PM, Aaron Spauldingprofessionalaa...@gmail.com wrote: It's not compiling for me. I'm getting: XFree86.h: No such file or directory. Doesn't look like it in the repo.
Re: [OpenFontLibrary] What licenses do we accept?
Fontaine revision 29 now adds GUST font license detection too ... Thanks! Where do I get that revision? ;-) ~ svn co https://fontaine.svn.sourceforge.net/svnroot/fontaine Or, if you already have a source code tree: ~ svn update - Ed
Re: [OpenFontLibrary] What licenses do we accept?
Hi, Nicolas, (1) I'll work on chasing down the deprecated licenses you mention. This is straightforward to do. (2) The CC Licenses are actually the ones that I find most confusing ... Could someone provide me the names and links to actual fonts licensed under CC licenses so I can see what the authors have included in the Copyright and License fields? - Ed Hi Ed, In the project-and-organisation-specific deprecated category we may want to add detection for the following licensing models: - Utopia - Baekmuk - GUST - Hershey - Lucida - Stix - Wadalab - mplus - Mincho And a profile to detect any CC-licensed fonts to flag them up. template.h provides a template for extending Fontaine to recognize additional licenses. I'll provide the patch for MIT. Best - Ed Cheers, -- Nicolas Spalinger, NRSI volunteer Debian/Ubuntu font teams / OpenFontLibrary http://planet.open-fonts.org
Re: [OpenFontLibrary] What licenses do we accept?
Hi, Nicolas (Mailhot), Vollkorn http://www.grafikfritze.de/?p=43 This appears to be a very nice font. The web page says its under a CC license -- but which one? In any case, the License field within the font itself only says Copyright (c) FRiTZe, 2006. All rights reserved. So Fontaine can only conclude Unknown or Proprietary License! Does anyone know this font author? Perhaps someone could write to him, suggesting he fill in the Copyright/License fields directly in the font file itself. Also, we really need to know very specifically which CC license. CC by itself is almost useless, I think (I could be wrong ...) Best - Ed
Re: [OpenFontLibrary] What licenses do we accept?
Hi, Nicolas et al., Do the Adobe-licensed-to-TeX Utopia fonts exist in a TrueType or OpenType packaging? Heuristica is a transformation to OpenType (CFF TT) ftp://ftp.dvo.ru/pub/Font/heuristica/ It's been relicensed to the OFL, which seemed compatible with the TUG grant when we looked at it. OK, I just checked in Fontaine SVN version no. 27 which now detects Adobe's license to TUG for the Utopia family. Tested using Heuristica. The license fields in the Heuristica font files indeed contain the original Abobe-TUG license wording, Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights ... If this font is really and legitimately licensed under OFL, then shouldn't the license field just say OFL? - Ed
Re: [OpenFontLibrary] What licenses do we accept?
The Yanone fonts have a similar problem: web page says CC (Generic CC) but the font header only says Copyright (c) Yanone, 2005. All rights reserved. ... so the font file itself fails to identify a license as far as I can see. On Wed, Jul 15, 2009 at 12:09 PM, nicolas.mail...@laposte.net wrote: Hi, Nicolas et al., Do the Adobe-licensed-to-TeX Utopia fonts exist in a TrueType or OpenType packaging? Heuristica is a transformation to OpenType (CFF TT) ftp://ftp.dvo.ru/pub/Font/heuristica/ It's been relicensed to the OFL, which seemed compatible with the TUG grant when we looked at it. http://bugzilla.redhat.com/show_bug.cgi?id=452317 OK, I just checked in Fontaine SVN version no. 27 which now detects Adobe's license to TUG for the Utopia family. Tested using Heuristica. The license fields in the Heuristica font files indeed contain the original Abobe-TUG license wording, Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights ... If this font is really and legitimately licensed under OFL, then shouldn't the license field just say OFL? Feel free to ask it of the font author:p
Re: [OpenFontLibrary] What licenses do we accept?
On Wed, Jul 15, 2009 at 12:34 PM, nicolas.mail...@laposte.net wrote: The Yanone fonts have a similar problem: web page says CC (Generic CC) but the font header only says Copyright (c) Yanone, 2005. All rights reserved. ... so the font file itself fails to identify a license as far as I can see. It's linked on the homepage and included in the zip :p I'd rather have it this way than the other (some metadata but no detached license) I would prefer to see both: (1) meta data in font files clearly identifies the license and (2) Separate text file called license.txt or LICENSE.txt or LICENSE in the downloaded package also clearly identifies the license ... In any case, if the license/copyright field in the font files themselves lack the information, then software like Fontaine can't make any automated determination . - Ed
Re: [OpenFontLibrary] What licenses do we accept?
Hi Ed, In the project-and-organisation-specific deprecated category we may want to add detection for the following licensing models: - Utopia - Baekmuk ... Baekmuk font files also do not identify the license in any clear way ... :-( - GUST - Hershey - Lucida - Stix - Wadalab - mplus - Mincho
Re: [OpenFontLibrary] What licenses do we accept?
Hi, Nicolas, Hi Ed, In the project-and-organisation-specific deprecated category we may want to add detection for the following licensing models: - Utopia ADDED TO FONTAINE. TESTED USING HEURISTICA FONT FAMILY. - Baekmuk *NOT* ADDED. BAEKMUK FONT FILES DO NOT MENTION THE LICENSE ... - GUST *NOT* ADDED. Are there any GUST fonts in TTF or OTF format? - Hershey *NOT* ADDED. Are there any Hershey-license fonts in TTF or OTF format? - Lucida *NOT* ADDED. Are there any Lucida-license fonts in TTF or OTF format? - Stix ADDED, BUT MARKED AS DEPRECATED SINCE STIX HAS THEORETICALLY MOVED TO OFL ... - Wadalab *NOT* ADDED. Wadalab fonts don't appear to be in TTF or OTF formats ... - mplus ADDED. - Mincho *NOT* ADDED. A lot of Japanese fonts are Mincho -- no clue which font project or license this refers to? I'll provide the patch for MIT. ADDED. But not yet tested ... need an MIT-licensed font in a TTF or OTF package ... WRT the short truncation of the Copyright field in the display produced by Fontaine: this was done because I was mainly thinking of displaying Fontaine's output in a summary tabular form on web pages. Sometimes the copyright field extends for pages and pages. I didn't want that. Feel free to suggest an appropriate length other than my admittedly very short 70 character length. What do folks feel would be appropriate? Note that internally Fontaine scans the entire copyright string, regardless of how long it may be. But it currently only prints a short snippet in the output report ... Best - Ed
Re: [OpenFontLibrary] What licenses do we accept?
Hi, Khaled, I'm not sure in what sense using Type1 fonts would screw up the rest of the system. TeX fonts has always been a different territory, and aren't supposed to integrate with the rest of the system anyway. Technically speaking, TeX is frozen and will never get updated, Even though new TeX-based engines support OpenType (XeTeX and LuaTeX), there still people who aren't willing to switch, for valid reasons, and will keep use those obsolete formates. So, distros have either to support these use scenarios or screw up their users, it is up to them. And as Type1 is a valid font formate (I just checked, and my GTK+ apps can use it) and I don't see a point for OFLB not to support it. OFLB may well support Type1. However at the moment there is an implementation detail which is: Fontaine does not yet fully investigate all aspects of a Type1 font. For example, Fontaine currently only investigates the Copyright and License fields in TrueType and OTF fonts, but not in Type1 Postscript fonts. Fontaine, which uses FreeType2, can of course be improved to do a better job with Type1 fonts. I just need to have the time to do the coding. So that's why today I was just looking for TTF or OTF fonts for testing ... Best Wishes -- Ed Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpeNP4ACgkQRoqITGOuyPJWzACfa2JlYJuT12ixJcRJjTT1uMge 3LQAni2qCtTN7/KFZUKnqZMS7qsMUgOp =qTKh -END PGP SIGNATURE-
Re: [OpenFontLibrary] What licenses do we accept?
OK, everyone, Fontaine revision 29 now adds GUST font license detection too ... Best - Ed 2009/7/15 Nicolas Mailhot nicolas.mail...@laposte.net: Le mercredi 15 juillet 2009 à 15:12 -0400, Ed Trager a écrit : - GUST *NOT* ADDED. Are there any GUST fonts in TTF or OTF format? Lots http://www.gust.org.pl/projects/e-foundry/tex-gyre/whole Though unfortunately they derived GPL ghostscript fonts and slapped their own license on the result (and seem decided to go on at all costs) IIRC some other GUST fonts are also released in OpenType format, and should not be problematic, for example http://nowacki.strefa.pl/torunska-e.html http://nowacki.strefa.pl/poltawski-e.html http://nowacki.strefa.pl/kurier.html It's such a pity the GUST guys seem to have no legal sense, their font work is great -- Nicolas Mailhot
Re: [OpenFontLibrary] What licenses do we accept?
Hi, all, In reply to Dave's question, under the src/licenses subdirectory in Fontaine's code tree we find: ~/fontaine/trunk/src/licenses $ ls Aladdin.hGPL.h licenses.h template.h ArphicPublic.h GPLWithFontException.h Magenta.h UnknownLicense.h BitstreamVera.h IPA.h OFL.h Freeware.h LGPL.h PublicDomain.h template.h provides a template for extending Fontaine to recognize additional licenses. Best - Ed Ed: please take a minute to confirm which licenses Fontaine recognises at the moment :-) -- Regards, Dave
Re: [OpenFontLibrary] Using genetic algorithms to create fonts
An interesting idea, Aaron ... ... but I could not identify even one letter correctly, and the offspring were equally unidentifiable ... Best - Ed On Fri, Jul 3, 2009 at 2:19 PM, Aaron Spauldingprofessionalaa...@gmail.com wrote: About a month ago I was thinking about what happen if fonts would be able to adapt to the reader? If each person had a font would they differ wildly? or would they be similar? I started working on a basic implementation of an adaptive font, it uses a genetic algorithm, to select the best letters or numbers. http://code.sachimp.com/labs/genetic_font_editor/ -- Aaron sachimp.com getCorkd.com
Re: [OpenFontLibrary] Using genetic algorithms to create fonts
Hi, Aaron, I don't really know anything about genetic programming algorithms since I've never done that kind of work. But I guess there has to be a fitness criteria in there somewhere that determines whether the offspring live to reproduce or die. That fitness criteria clearly needs to be based on whether people can read the letters or not. So maybe some kind of voting system? More highly-ranked ones have more chances to mate and produce offspring, less highly-ranked ones die sooner with fewer offspring. Something like that ... Best - Ed On Fri, Jul 10, 2009 at 12:26 PM, Aaron Spauldingprofessionalaa...@gmail.com wrote: Ed Trager wrote: An interesting idea, Aaron ... ... but I could not identify even one letter correctly, and the offspring were equally unidentifiable ... Yeah, thats the problem. I didn't want to bias the result, but I also don't want it to take millions years. I'm thinking of pre-populating the database, but I'm open for input. Best - Ed -- Aaron sachimp.com getCorkd.com
Re: [OpenFontLibrary] theleagueofmoveabletype.com is switching to the Open Font License
That's great! - Ed On Thu, Jun 4, 2009 at 5:28 PM, Dave Crossland d...@lab6.com wrote: Happy days :-) -- Forwarded message -- From: The League of Moveable Type Date: 2009/6/4 Subject: Re: Please consider switching to the Open Font License To: Dave Crossland Hello Dave, Caroline here, thanks for getting in touch. Actually, we are thinking of switching to the SIL Open Font License, it's just a matter of letting know our font contributors about the change. We agree, we think the Open Font License will work better for the purposes of The League. So we'll let you know when we've made the change. And thanks for the heads up! -Caroline The League of Moveable Type - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - www.theleagueofmoveabletype.com
Re: [OpenFontLibrary] Open Font Library Podcast: Dev Talk #1
Hi, everyone, On Wed, Jun 3, 2009 at 2:08 PM, Behdad Esfahbod beh...@behdad.org wrote: On 06/03/2009 02:02 PM, Ben Weiner wrote: Hi, Behdad Esfahbod wrote: Ok, listening. It still slightly worries me that all the new code being written is duplicating lots of code that is already out there... OK, well, please give us some more hints about which functionality we shouldn't be duplicating... ;-) pcp? The preview-generating tool. I want to see any missing features added to pango-view instead. pcfp is currently a very simple tool for generating the previews. Currently, pcfp just generates a single line of typeset text as a preview. I mentioned in the recorded development conversation with Ben Weiner and Dave Crossland that I may want in the future to add options to pcfp to make it capable of producing a waterfall specimen, or a drop caps specimen. I'm sure people on this list can think of a gazillion possibly useful options beyond just these few. I will certainly take a look at pango-view and see what it does and what options are there, and see where it is best to make additions or modifications in the future. Note that while pcfp is currently used for generating the previews, most of my time was actually spent on creating the FontPlayground and Key Curry Javascript classes that drive the interactive web interface. pcfp was something I needed on the server side, so I wrote pcfp (and it didn't take much time to do that): I'm sure that pango-view or similar tools can be swapped in place of pcfp if it is generally agreed that a more versatile tool with a better array of options is needed in the future. Fontaine also overlaps with fontconfig and pango in huge parts. I'm not as convinced that fontaine overlaps so extensively with fontconfig. The way orthographies are grouped in fontaine is quite different than in fontconfig. The treatment of Japanese illustrates the difference well: Fontaine breaks up Japanese into a set of categories that are meaningful to Japanese people: Jinmeiyo, Joyo, and Kokuji represent different classes of Kanji, and then there is of course a separate group for kana (hiragana, katakana). For a typographer working to produce a Japanese font, being able to generate a report where things are organized into these groupings makes sense. Fontconfig on the other hand --correct me if I am wrong-- has a single grouping for Japanese orthography, which lumps all the Kanji and kana. This is just one example. There are differences in the approach fontaine takes for other orthographies as well. Overall, the general distinction is that fontaine uses orthographic-centric groupings that are intended to be most relevant to fonts and digital type design. As I understand it, fontconfig uses language-centric groupings. There is of course nothing wrong with fontconfig's approach -- or, for that matter, with Fontaine's approach. They simply serve different purposes. I replied to that in another thread a couple montsh back. Maybe if I find some time I hack something... Also, Ed talks about fontconfig being a mystery. If someone doesn't understand some part of it, all they need to do is ask. I'll explain until they understand :). What happens if you get kidnapped or lose your internet connection? See, I write the code. Ed already contacted me and I told him how I think this should be done. He didn't CC the list (he's not on the list?) I'm on the list -- I wasn't paying attention when I emailed Behdad the other day, so I forgot to reply all or CC the list ... , so I attach the relevant parts at the end of this message. Anyway, point being that, now he knows how things work, and he's much better than me in writing. So he can write good docs! Same applies to everyone else: ask, I'll make sure I answer, you can then write it in a legible form :). Heh, heh, you are assuming that I like writing documentation ... Best - Ed behdad QUESTION: So, if I add a font file to a subdirectory of a directory that fontconfig knows about (via the fontconfig conf file), does fontconfig rescan that subdirectory and re-cache immediately? Any new process notices that immediately and updates the cache (make sure it has permission to do so). Or you can call FcInitReinitialize(). However, I strongly recommend that you keep all the font dirs out of the default fontconfig config, and add only the directory for the font you are dealing with into the config using FcConfigAppFontAddDir(). That should avoid lots of possible scalability as well as security issues. I'd even recommend using different cache dirs for each font dir. Or, alternatively, is it necessary to call fc-cache manually? SCENARIO: The scenario for uploading new fonts to OFLB is that the fonts will be placed in a subdirectory of the files/ path. The fontconfig conf file will know about the parent directory called files/. A new subdirectory under files/ may be created at any time to
Re: [OpenFontLibrary] AdBard?
Seems reasonable to me. The adBard ads don't look too bad. - Ed Trager On Tue, Jun 2, 2009 at 10:23 AM, Dave Crossland d...@lab6.com wrote: Hi, How do people feel about AdBard adverts of the OFLB site to raise money for development? -- Forwarded message -- From: Peter Brown pet...@fsf.org Date: 2009/6/2 Subject: [FSF] FSF welcomes AdBard network for free software advertising To: info-...@gnu.org http://www.fsf.org/news/ad-bard The Free Software Community now has an ethical alternative to ad networks that promote proprietary software FSF welcomes AdBard network for free software advertising BOSTON, Massachusetts, USA -- Tuesday June 2, 2009 -- The Free Software Foundation (FSF) today welcomed the launch of AdBard a new advertising network for technology based websites based upon the promotion of Free, Libre and Open Source Software (FLOSS) friendly products and services. The AdBard Network has been created by Tag1 Consulting to serve websites dedicated to free software ideals, helping them connect with companies selling products and services targeting a FLOSS audience. AdBard solves the problem that more generic advertising has led to the display of proprietary software products on sites that otherwise promote computer user freedom. The Free Software Community now has an ethical alternative to ad networks that promote proprietary software said Peter Brown, Executive Director of the Free Software Foundation. This is a huge win for many of the sites that serve our community. And we wish AdBard and the websites that display AdBard adverts every success. We also hope this will inspire other ad networks to adopt similar policies. AdBard is a great way for advertisers and publishers in the free software community to come together and help grow the free software services market. said Jeremy Andrew, CEO of Tag1. The FSF receives no money from AdBard and has no financial interest in Tag1 Consulting, but is making this announcement to help the advertising-supported web sites in the free software community to stop legitimizing proprietary software by advertising it. Websites already using AdBard include http://Kerneltrap.org, http://Libre.FM and http://BoycottNovell.com. For a complete list visit http://adbard.net/adbard/websites. Advertisers can find out more by visiting http://adbard.net/advertise. About the Free Software Foundation The Free Software Foundation, founded in 1985, is dedicated to promoting computer users' right to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free (as in freedom) software -- particularly the GNU operating system and its GNU/Linux variants -- and free documentation for free software. The FSF also helps to spread awareness of the ethical and political issues of freedom in the use of software, and its Web sites, located at fsf.org and gnu.org, are an important source of information about GNU/Linux. Donations to support the FSF's work can be made at http://donate.fsf.org. Its headquarters are in Boston, MA, USA. About Tag1 Consulting, Inc. Tag1 Consulting, Inc. is a distinguished professional consulting company headquartered in sunny Florida, with an international presence providing computer consulting services worldwide. Tag1 focuses on performance and scalability consulting of GNU/Linux and *BSD, using Apache, PHP, MySQL and PostgreSQL, specializing on Drupal performance. For more information visit www.tag1consulting.com. Media Contact Matt Lee Campaigns Manager Free Software Foundation PHONE +1 (617) 542 5942 x25 campai...@fsf.org ### -- Peter T. Brown Executive Director Free Software Foundation| Tel: +1-617-542-5942 www.fsf.org www.gnu.org | Cell: +1-617-319-5832
Re: [OpenFontLibrary] multiple fonts in a single file
Hi, Ben, The Debian CJK project files are TTC. But they don't contain normal/italic/bold/etc/ variants. Instead, there are glyph variants that are relevant to Chinese vs. Japanese typographic tradition differences. I don't know of any Libre TTC files. Maybe something designed for Apple OS X, perhaps? I believe TTC may be used a bit on Apple. As far as Fontaine goes, it will definitely see the first font face in a TTC package. But I'm reasonably certain that I don't yet have code to specifically handle the case of TTC files. Best - Ed On Fri, May 22, 2009 at 12:24 PM, Ben Weiner b...@readingtype.org.uk wrote: Hi there, Has anyone got a sample font file that contains more than one variant (say, both roman and italic)? I'd like to test the new OFLB site against it. Thanks, Ben -- Ben Weiner | http://readingtype.org.uk/about/contact.html
Re: [OpenFontLibrary] use of (c) typefaces
On Fri, May 8, 2009 at 10:07 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Hi, Maybe we should have some kind of WhatTheFont client in admin panel to check uploaded fonts for being actually (c) typefaces? How does one do that? Tell us the technical details. The program I wrote, Fontaine, determines the license from the Copyright field. We can use that to prevent storage of Fonts which lack an approved Open Source license. But I assume that the problem you are really trying to address is one of people copying glyph outlines into a new font that they claim to be their own? For that kind of situation, one would, I assume, have to try to match glyph outlines against some searchable database of glyph outlines ... sounds hard to do ... Best - Ed Alexandre
Re: [OpenFontLibrary] use of (c) typefaces
Hi, Alexandre, On Fri, May 8, 2009 at 10:17 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Fri, May 8, 2009 at 6:15 PM, Ed Trager wrote: But I assume that the problem you are really trying to address is one of people copying glyph outlines into a new font that they claim to be their own? Yes For that kind of situation, one would, I assume, have to try to match glyph outlines against some searchable database of glyph outlines ... Exactly what I say :) sounds hard to do ... But it works Does it? If someone was going to copy glyphs from some other font, they might either intentionally --or indeed completely *unintentionally*-- make changes to the glyph outlines. Visually the glyphs would still look very close to the originals, but the actual points and curves might be sufficiently different from the original to avoid detection by most simple matching algorithms. For example, instead of copying glyphs electronically, someone might scan printed pages at a reasonable degree of resolution, then use bitmap tracing to re-vectorize the glyphs. Indeed, for legitimate revivals of old printed typefaces that are in public domain, a number of useful tools and scripts are available exactly for the purpose of reviving old typefaces as modern digital revivals. Any revival from scanned images will certainly result in unique outline vectorizations that will always differ from the originals (in the case where the originals were in fact produced from digital type). So in fact it now seems to me that having a database of *outlines* will be useless. A better approach would be to create a database of *bitmaps* of the glyphs at some sufficiently high pre-defined resolution. Then, to test a suspicious font, one would in fact rasterize the glyphs to a set of bitmaps at the same pre-defined resolution, then overlay and subtract one bitmap from the other (i.e., do some sort of pixel-aligned XOR operation on the two bitmaps) and see what was left over. If nothing or very little was left over, that could be used to flag a font for review by a human. Something like this would probably work ... Is this the idea you had, or some other idea? Alexandre
Re: [OpenFontLibrary] use of (c) typefaces
Hi, all, On Fri, May 8, 2009 at 10:36 AM, Ben Weiner b...@readingtype.org.uk wrote: Hi, Alexandre Prokoudine wrote: Hi, Maybe we should have some kind of WhatTheFont client in admin panel to check uploaded fonts for being actually (c) typefaces As Ed Trager says in his reply, Fontaine reads license fields from uploaded fonts. Fontaine is an important part of the OFLB not least for that reason. I think that reading the license from the file is a good thing to do. I think trying to match outlines is less good. The first is like a tick in a box (Is this font correctly licensed?). The second is like saying We don't trust you. So we checked up on you! You are bad because our algorithm said so! This reminds me of the surveillance/database state - something that is happening very quickly in the UK and makes me unhappy. So that is an emotionally-coloured answer :-( What the Font is a great tool though - love it ;-) What the Font indeed must work by analyzing bitmaps more or less using the principle I described in my previous posting of subtracting a test bitmap from a known bitmap in the database and looking at the residue left over : less residue means a better match. It still seems like a hard problem to me: First, in the case of a system like WhatTheFont, you must have a good algorithm for aligning and scaling bitmaps to the right size before trying to subtract one from the other. Secondly, if you have a large database of bitmaps, just using a brute-force approach to match the test glyph bitmap against every bitmap in the database seems inefficient ... Ideally one would want a way to create some sort of digital fingerprint from the full bitmap that could be used as an index key for rapid retrieval of closely-matched glyph bitmaps. Of course there have got to be ways to do this. But, as I said, it seems like quite a bit of work to me ... In fact, I wish I knew about some of the ideas for doing such fingerprinting of similar images for the purposes of indexing, etc. : Knowing how to do that would also provide a nice way to show a user related fonts. Similar to what web sites like Amazon Books does, but for fonts: If you like this font, take a look at these similar fonts ... - Ed Cheers, Ben -- Ben Weiner | http://readingtype.org.uk/about/contact.html
Re: [OpenFontLibrary] Incomplete fonts/dingbat fonts
Do the dingbat fonts on OFLB have Unicode CMAPs? Are they putting the dingbat glyphs in the Dingbat symbols block, or just randomly in the ASCII or Latin-1 blocks? Fontaine obviously can't tell what the glyphs look like. Currently Fontaine does not have an orthography file for the dingbat symbols block, but that can be changed of course. Fontaine does currently have orthography files for the mathematical operators and chess symbols blocks, so obviously additional symbol blocks can be added. I don't see why a font that covered only certain symbol blocks -- Dingbats, chess symbols, mathematical operators, or otherwise-- should not be allowed on OFLB. In the future one will be able to search for fonts meeting certain criteria -- such as covering a specific orthographic block -- so as long as such fonts are properly constructed (i.e. have a Unicode CMAP) and can be properly categorized in the site's database, why not? Best - Ed On Tue, Apr 21, 2009 at 7:25 AM, Ben Weiner b...@readingtype.org.uk wrote: Hi, Dave Crossland wrote: We have agreed, I think, that we want OFLB to be a source to visitors of quality fonts, not lots of dross. Ed's fontaine is going to check unicode coverage of fonts, and testing it I found that a font I'm developing, with only lowercase glyphs, fails the coverage check since its a latin1 encoded font without a cap A, and so its obviously not a fully useful font. Therefore OFLB ought to politely decline it as a submission and ask me to fill out the caps, I think. This raises a problem for dingbat fonts, which we have some of, which have random glyphs used. I think the solution there is to direct such fonts to OCAL, right? I would, tentatively, agree. Though thinking of the origins of OFLB I suspect they might wish to direct dingbats back here ;-) Ben -- Ben Weiner | http://readingtype.org.uk/about/contact.html
Re: [OpenFontLibrary] OFL problems, IPA License annoyances
Hi, All, I've added IPA license detection to Fontaine: r20 | edtrager | 2009-04-06 17:40:31 -0400 (Mon, 06 Apr 2009) | 1 line Added Information-technology Promotion Agency, Japan (IPA) license which is now an Open Source approved license (http://opensource.org/licenses/ipafont.html). Thanks to Dave Crossland for this information. - Ed On Mon, Apr 6, 2009 at 3:54 PM, Dave Crossland d...@lab6.com wrote: Hi, More licensing curmudgeon-ry from me I'm afraid :-) A new OSI approved font license is out, the Japanese IPA Font License: http://opensource.org/licenses/ipafont.html The OFLB is only going to run with the most popular free font licenses, to encourage license consolidation, so I doubt the OFLB will accept IFL fonts anyway. So, if you're not interested in font licensing, please note the existence of the license and mark this thread as read :-) I wonder if the story of its creation will be published to the same extent that the SIL OFL process has been documented; I guess that there was some kind of wrestling match between proprietary-minded font developers and freedom-minded customers. Some of the history is revealed with a quick search: Bruce Perens has been helpfully guiding the drafts of this - http://perens.com/blog/?s=open+font - although, sadly, his original objections which I share about only distributing derived versions as diff files - http://www.crynwr.com/cgi-bin/ezmlm-cgi?17:mss:516:200902:ahjoeececbbcpiajppfi - apply to the final OSI approved license. Although I'm happy some Japanese fonts are being released with an OSI approved license, this diff requirement makes it a very poor license IMO. The draft Perens linked to at http://ipafont.ipa.go.jp/enduser_license_draft090304.pdf has the makings of a much better license, and is probably only interesting to me so I'll skip over my thoughts about it here. However, the key thing about the license is that it (appears to) patch the PDF loophole that Perens claims the SIL OFL has at http://perens.com/blog/2009/02/17/64/ loophole that would allow the conversion of any font under the license to public domain OFL S5: he Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. - http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=OFL_web IFL S2.4: In the case of a Digital Document File containing Embedded Fonts created by embedding such fonts to the extent allowed under this Agreement, the Recipient may conduct Reproduction and Other Exploitation of the Digital Document File, without requiring the Recipient of such Digital Document File to comply with this Agreement. For the avoidance of doubt, such Recipient may not create and conduct Reproduction and Other Exploitation of a Derived Program from such Digital Document File except according to the terms of this Agreement. - http://opensource.org/licenses/ipafont.html I hope this will help in the updating of the GNU GPL Font Exception :-) Cheers Dave
[OpenFontLibrary] Fontaine Announcement
* ANNOUNCING FONTAINE * Hi, everyone, Fontaine is a command-line utility that displays key meta information about font files, including but not limited to font name, style, weight, glyph count, character count, copyright, license information and orthographic coverage. The software is released under the GNU General Public License (GPL) v. 2 or any later version. I am writing this software initially for use with the Open Font Library project (OFLB). The OFLB project is still in the works and as a result it is accurate to say that Fontaine is also still in the works. Nevertheless, I believe that Fontaine will have application outside of the OFLB project. In order to meet various possible application needs, Fontaine has the ability to produce reports in JSON, XML, XHTML, and TEXT formats. I have created a web page documenting Fontaine on Unifont.org: http://www.unifont.org/fontaine/ I have also created a Sourceforge.net project for Fontaine: http://sourceforge.net/projects/fontaine/ ... and the source code is available for checkout from SVN: svn co https://fontaine.svn.sourceforge.net/svnroot/fontaine I plan to create an interactive web page which will demonstrate how Fontaine works. However I haven't got quite that far yet. The software uses a CMAKE-based build system and is known to work on Linux and OSX. It has not yet been extensively tested on other platforms. Some features which will be needed for the OFLB site are still missing and implementing those features will take priority. Help on completing, vetting, and expanding the orthography data files will be especially welcome. An initial list of known bugs is shown on the unifont.org/fontaine web page. Suggestions for further improvement and patches for bug fixes are welcome. Note that in many cases Fontaine reports on entire orthography groups (such as Western European, Central European, Pan African Latin, etc.) rather than on individual languages the way that software like FontConfig does. The orthography work I have done for Fontaine has required striking a careful balance between opposing forces -- simplicity and generality versus specificity. At the extremes, there are pervasively adopted scripts (like Latin) and singularly adopted scripts (like Japanese). Those opposing forces operate differently on different scripts, especially at the extremes of the continuum. Fontaine thus uses its own set of orthography files in order to provide reports in ways that are, to the best of my abilities, most meaningful in the context of fonts. Fontaine is new, so certainly the jury is still out regarding whether I have made the right decisions here, but I thought this especially worth mentioning given the recent and very laudable work on orthography files in FontConfig. Best Wishes -- Ed Trager
[OpenFontLibrary] Text Layout and Typography Working Group at LGM (1) URLs for the wikis (2) Accomodations
Hi, everyone, (1) WIKI URLs: You probably already know these, but just a quick update in case you don't: 1.1. Text Layout and Typography 2009 wiki is at: http://www.freedesktop.org/wiki/TextLayout2009 1.2. I also have added the Text Layout and Typography 2009 meeting under Presenters and Talks on the LGM wiki as follows: http://create.freedesktop.org/wiki/index.php/Conference#Presenters_and_Talks (2) ACCOMODATIONS: According to the LGM Wiki, there will be MULTI-style dorm rooms holding 3 people for apx. CAD $66 (to be confirmed). Those of you who attended TLM in Glasgow may remember that we booked a big dorm room at a very reasonable price and that seemed to work out really well for people. So if any of you are interested in a similar inexpensive but congenial arrangement for the Text Layout meeting this year, please let me know and I will work on reserving rooms. The sooner folks let me know, the more likely we will be successful at reserving the limited number of multi rooms available. Best Wishes -- Ed Trager
[OpenFontLibrary] 2009 TEXT LAYOUT AND TYPOGRAPHY WORKSHOP / MEETING SURVEY
Hi, Eric, No decision yet. I suspect that LGM is probably the preferred venue, but I don't really have enough data to back that assumption. So if a few more people want to voice their preference, then I promise to actually do something. Sorry, I've been completely swamped with other projects, but if people want to help me out by quickly responding to the little survey below, then I think we can move things forward quite quickly :-) = 2009 TEXT LAYOUT AND TYPOGRAPHY WORKSHOP / MEETING SURVEY = (1) VENUE. I PREFER THE FOLLOWING VENUE: [ ] LGM in Montreál 6-9 May 2009 ( http://www.libregraphicsmeeting.org/2009/ ) [ ] Linux Found. Collab. Summit Apr 8-10, 2009 in San Fransisco http://events.linuxfoundation.org/events/collaboration-summit [ ] OTHER (write in): __ (2) ATTENDANCE: [ ] I plan to attend. [ ] Sorry, can't make it. [ ] I want to be able to follow along remotely via streaming video and IRC, Skype conference call, and/or other digital access technology (3) PRESENTATION TOPICS: [ ] I want to present on (topic): [ ] I can't be there in person, but I want to submit a paper/presentation/video on: (topic): _ (We can arrange to have someone present on your behalf, if you want) [ ] I want somebody to present on:_ (4) CODE: [ ] I want to hack on (project:) __ during the gathering (5) FOOD AND BEVERAGE: Check all that you like or just write in something ... [ ] Sugar Shack [ ] Pizza [ ] Cheetos [ ] Pho [ ] Plaa chu-chi [ ] Kendall Jackson 2004 Taylor Peak Estate Merlot [ ] Gordon Biersch [ ] Unibroue (6) ADD YOUR OWN STUFF HERE: ... Best to everyone -- Ed On Fri, Feb 20, 2009 at 12:11 PM, Eric Mader ema...@icu-project.org wrote: Hi, Did the location for the 2009 Text Layout and Typography Workshop ever get decided? Regards, Eric Mader Ed Trager wrote: Hi, everyone, Is there interest in having a Text Layout and Typography Workgroup meeting at this year's upcoming LF Collaboration Summit April 8-10 (Wed-Fri) in San Fransisco? If so, please email back complete with agenda ideas. I will be happy to take the initial lead in organizing an agenda and reserving space with the Collaboration Summit folks if I hear back from interested folks. In order to reserve space, I need to get some kind of ballpark head count, so respond if you are interested. Ideally I'd like to be able to communicate back to the organizers next week so we can reserve space in a timely manner. Best Wishes -- Ed Trager
Re: [OpenFontLibrary] @font-face, is it really needed for font preview?
Hi, Khaled, You are correct that the Font Playground previewer I wrote provides dynamic previews using server-generated PNG images and AJAX for communication. It currently works using a div-based popup-window which I thought would be a good way to avoid gobbling up too much screen real estate -- especially when you consider the fact that a single font may have a number of style variants. I also wrote an additional bit of Javascript which attempts to dynamically detect whether the browser provides @font-face support or not. As far as I know, that javascript has not yet been incorporated into the new site. This bit of javascript in theory will allow a site like OFLB to dynamically alter the display of a page based on whether @font-face support is present or not. Here is the demo page -- feel free to look at the javascript under the hood and improve it if possible: http://eyegene.ophthy.med.umich.edu/fontface/ Also although that bit of Javascript code is as reliable as I could get it to be, at this point in time the browsers are *not* yet reliable with regard to @font-face support. So the Javascript may report a browser as having support because the foundational stuff is already incorporated into the browser code, but the support may not yet work (Google Chrome, based on WebKit, is a good example of this). There are also versions of Opera and Firefox out there that purport to support @font-face but don't really, or do so only partially. For example, some support TTF but fail on OTF fonts on one platform or another. I think I have my http://eyegene.ophthy.med.umich.edu/fontface/ URL currently set only for testing a couple of TTF files -- I had previously used OTF files which often didn't work and left me quite confused. -- Ed On Mon, Feb 9, 2009 at 10:29 AM, Khaled Hosny khaledho...@eglug.org wrote: The new OFLB website uses @font-face CSS property for font preview, but I wonder if we really need it? Most browsers don't support it, even with the release of Firefox 3.1 we still have around 70% of web users with browsers that don't support it. Even if we put this aside, why I need to download a several megabits font just to get a static preview of it, it isn't even dynamic, what is the benefit (some Arabic or CJK fonts are even larger). Don't get me wrong, I find @font-face very great feature, but I think we are misusing it here. I think generating server side previews gives more better and responsive user experience, I think font playground already does this, just we need to merge it into the main body of the page instead of the current hidden (and annoying) separate popup (or whatever it is called). Regards, Khaled -- Khaled Hosny Arabic localizer and member of Arabeyes.org team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmQS+UACgkQRoqITGOuyPIgZgCeKnapT7eoGmY3SKhRdUgtROwq ys4An1fl1UzKxbJi74bpi/DaKq58n50M =blSJ -END PGP SIGNATURE-
Re: [OpenFontLibrary] @font-face, is it really needed for font preview?
Hi, Egil, I and others have thought of this before too. I think someone connected to SIL's Graphite project worked on something along these lines in order to support complex layout scripts like Burmese in the current crop of SVG-aware but Burmese-not-aware browsers. To write a server-side program that generates a bitmap image of text is fairly simple. To write a server-side program that generates the SVG snippets instead is more work. However such an SVG curve generator would be pretty cool because then you could scale the text dynamically on the client side, change colors using CSS, and generally have a lot of fun playing around with the SVG outlines directly on the client side. So it would be quite cool if someone did it. -- Ed On Mon, Feb 9, 2009 at 10:44 AM, Egil Möller egil.mol...@freecode.no wrote: Quite a few webbrowsers used today seems to support SVG images. Maybe rendering the preview to SVG (curves) would work? Khaled Hosny wrote: The new OFLB website uses @font-face CSS property for font preview, but I wonder if we really need it? Most browsers don't support it, even with the release of Firefox 3.1 we still have around 70% of web users with browsers that don't support it. Even if we put this aside, why I need to download a several megabits font just to get a static preview of it, it isn't even dynamic, what is the benefit (some Arabic or CJK fonts are even larger). Don't get me wrong, I find @font-face very great feature, but I think we are misusing it here. I think generating server side previews gives more better and responsive user experience, I think font playground already does this, just we need to merge it into the main body of the page instead of the current hidden (and annoying) separate popup (or whatever it is called). Regards, Khaled -- Konsulent, Fri Programvare / Free Software Consultant Mobil: +47 - 473 44 024 Telefon: +47 - 21 53 69 00, Fax: +47 - 21 53 69 09 Adr: Nydalsveien 30b, 3. etg., 0484 Oslo Web: www.freecode.no Check out our published Free Software @ http://code.freecode.no.
Re: [OpenFontLibrary] @font-face, is it really needed for font preview?
Hi, Nicolas, Getting the SVG output small enough would really not be a problem. There are serveral ways to do it: * One way is to send over the SVG data but be sure to use CSS classes for the styling. A lot of SVG graphics programs inline too much style information repeatedly, which is uneccessary. * Another approach would be to send back the curve data in a more minimalistic XML or JSON format, and then actually have Javascript classes that flesh out the data into SVG. I've actually taken this approach before for loading X-Y plot data dynamically -- see demo at http://eyegene.ophthy.med.umich.edu/gladiatorcomponents/plot.html -- Ed On Mon, Feb 9, 2009 at 11:00 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 9 février 2009 16:44, Egil Möller a écrit : Quite a few webbrowsers used today seems to support SVG images. Maybe rendering the preview to SVG (curves) would work? BTW if someone could spend the time to write a SVG preview generator that could be integrated in web sites and package generation processes, that would be great. The constrains are basically to generate the preview for a random number of font files taken as input, with an SVG output that showcases the main scripts the font files support (that means script detection using fontconfig, heuristics to select the most interesting glyphs to showcase, pangrams? and an svgz output small enough to be integrated everywhere) -- Nicolas Mailhot
Re: [OpenFontLibrary] @font-face, is it really needed for font preview?
A FontForge script would be sufficient for showing individual glyphs or even laying out text for simple scripts like Latin, Greek, Cyrillic, etc. But don't forget that it would be insufficient for showing text in complex text layout (CTL) scripts like Arabic and Devanagari ... for those you need a shaper library like Pango or Uniscribe. -- Ed On Mon, Feb 9, 2009 at 11:09 AM, Daniel Johnson il.basso.bu...@gmail.com wrote: On Mon, Feb 9, 2009 at 11:03 AM, Ed Trager ed.tra...@gmail.com wrote: To write a server-side program that generates a bitmap image of text is fairly simple. To write a server-side program that generates the SVG snippets instead is more work. However such an SVG curve generator would be pretty cool because then you could scale the text dynamically on the client side, change colors using CSS, and generally have a lot of fun playing around with the SVG outlines directly on the client side. So it would be quite cool if someone did it. It would be trivial to write a FontForge script that generated an SVG font anytime someone uploaded a new .otf, .ttf or .sfd file. However, browser support for SVG fonts is virtually nonexistent. As I recall reading, Firefox support for SVG fonts missed the 3.1 feature deadline. It's possible to turn an SVG font into a series of standard SVG shapes; all you need to do is a vertical flip and some scaling -- a simple transform attribute on the g element surrounding the glyph. Regards, Daniel
Re: [OpenFontLibrary] @font-face, is it really needed for font preview?
Hi, Aaron, That's definitely worth looking into! - Ed On Mon, Feb 9, 2009 at 11:32 AM, Aaron Spaulding professionalaa...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ed, You're using Cairo for rendering the type specimens right? Could you not just use a SVG Surface instead? Aaron Ed Trager wrote: Hi, Egil, I and others have thought of this before too. I think someone connected to SIL's Graphite project worked on something along these lines in order to support complex layout scripts like Burmese in the current crop of SVG-aware but Burmese-not-aware browsers. To write a server-side program that generates a bitmap image of text is fairly simple. To write a server-side program that generates the SVG snippets instead is more work. However such an SVG curve generator would be pretty cool because then you could scale the text dynamically on the client side, change colors using CSS, and generally have a lot of fun playing around with the SVG outlines directly on the client side. So it would be quite cool if someone did it. -- Ed On Mon, Feb 9, 2009 at 10:44 AM, Egil Möller egil.mol...@freecode.no wrote: Quite a few webbrowsers used today seems to support SVG images. Maybe rendering the preview to SVG (curves) would work? Khaled Hosny wrote: The new OFLB website uses @font-face CSS property for font preview, but I wonder if we really need it? Most browsers don't support it, even with the release of Firefox 3.1 we still have around 70% of web users with browsers that don't support it. Even if we put this aside, why I need to download a several megabits font just to get a static preview of it, it isn't even dynamic, what is the benefit (some Arabic or CJK fonts are even larger). Don't get me wrong, I find @font-face very great feature, but I think we are misusing it here. I think generating server side previews gives more better and responsive user experience, I think font playground already does this, just we need to merge it into the main body of the page instead of the current hidden (and annoying) separate popup (or whatever it is called). Regards, Khaled -- Konsulent, Fri Programvare / Free Software Consultant Mobil: +47 - 473 44 024 Telefon: +47 - 21 53 69 00, Fax: +47 - 21 53 69 09 Adr: Nydalsveien 30b, 3. etg., 0484 Oslo Web: www.freecode.no Check out our published Free Software @ http://code.freecode.no. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmQWoMACgkQEO7oWqc3IdqT8ACgntFL+fv4tS3buP88CWdVMZV8 lhAAn0xWLbarcoOyR27ySODDoEbnT2YU =mE/I -END PGP SIGNATURE-
Re: [OpenFontLibrary] timeline + going live
Hi, Jon, I'm the guy currently working on a server-side font analysis program for OFLB. The idea is that when a user uploads a new font, the program analyzes the font to determine various properties of the font, including orthographic coverage, *inter alia*. The program's output report will inform OFLB whether, for example, a font covers only Western Latin or whether it also covers Central European, Turkish, or Vietnamese extended Latin characters. Similarly useful analyses will be performed for non-Latin scripts, if present in the font. The report results will then be stored so that users browsing available fonts will be able to instantly see coverage results. Eventually it should also be possible to search for fonts meeting specific coverage requirements, among other things. I personally believe that the font analysis program will form a key part of the new OFLB site. The font analysis program is currently in an alpha stage of development. I think I will have the program to a fairly decent beta stage by the middle of February. Integrating the program into the OFLB cms will also require development work and time. If I had to put forth an estimated completion date, I'd venture to say no sooner than the middle of March. There are probably other aspects of the development picture that I am not aware of, so it would be good to hear what Dave and Ben say. I can only address the area of site development that I am personally involved in. Best - Ed On Thu, Jan 15, 2009 at 3:34 AM, Jon Phillips j...@rejon.org wrote: Dave and Ben, what else is needed to get OFLB live? What timetable? I want to make sure we get good press launch out of things too. My head hasn't been so in the game, but want to make sure and assist on powerful lauch. You guys have and are doing great job! Jon -- Jon Phillips http://rejon.org/ San Francisco + Beijing GLOBAL +1.415.830.3884 . USA +1.510.499.0894 . CHINA +86.1.360.282.8624 IM/skype: kidproto - Jabber: re...@gristle.org http://rejon.org/bio . http://rejon.org/bio/cv . http://rejon.org/projects
Re: [OpenFontLibrary] Fwd: [CREATE] LGM 2009 update
Hi, Dave and everyone, The Text Layout working group has the option of holding a meeting in conjunction with either the Linux Foundation Collaboration Summit in San Fransisco in April, or in conjunction with LGM in Montreal in May. Do people have a preference on the venue? I put out an email yesterday asking if folks were interested in the LF San Fransisco venue and so far have received only one response. I'd like to know if people prefer LGM. For me personally Montreal would be easier to get to. Best - Ed On Thu, Jan 15, 2009 at 9:54 AM, Dave Crossland d...@lab6.com wrote: FYI :) How many people from OFLB are planning to attend LGM? I am :-) -- Forwarded message -- From: Louis Desjardins louis.desjard...@gmail.com Date: 2009/1/15 Subject: [CREATE] LGM 2009 update To: Create ML cre...@lists.freedesktop.org Hi all, I have updated the LGM wiki with the latest information. http://create.freedesktop.org/wiki/index.php/Conference Please review and comment here on this list or post questions on the wiki when you feel we are missing info. From now on I will be online either on IRC #lgm, here on the list or on the wiki. I will try to be as quick to react as possible! We're going to hit the accelerator pedal. There is so much I can do on the local side. I need help on the sponsors/pledgie campaign and on the website, mainly. Each LGM team should not be shy to file the wiki with presentations proposals. Please note that even if we have an extra day, we have reduced the number of slots in order to increase the time allowed for team meetings. Have a look and get back here! Cheers! Louis -- Louis Desjardins Organiser Libre Graphics Meeting 2009 - Montréal ___ CREATE mailing list cre...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create -- Regards, Dave Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software. - Bill Gates, 1976, in want of www.gnuherds.org
[OpenFontLibrary] Fwd: [Desktop_architects] Collaboration Summit Meeting Space
Hi, everyone, Is there interest in having a Text Layout and Typography Workgroup meeting at this year's upcoming LF Collaboration Summit April 8-10 (Wed-Fri) in San Fransisco? If so, please email back complete with agenda ideas. I will be happy to take the initial lead in organizing an agenda and reserving space with the Collaboration Summit folks if I hear back from interested folks. In order to reserve space, I need to get some kind of ballpark head count, so respond if you are interested. Ideally I'd like to be able to communicate back to the organizers next week so we can reserve space in a timely manner. Best Wishes -- Ed Trager -- Forwarded message -- From: C. Craig Ross c...@linuxfoundation.org Date: Fri, Jan 9, 2009 at 2:55 PM Subject: [Desktop_architects] Collaboration Summit Meeting Space To: desktop_archite...@linuxfoundation.org Hello and Happy New Year. The 2009 Collaboration Summit (April 8-10, 2009, San Francisco, CA) is coming up quickly and we have already started preparing the schedule. It is very important for LF to provide a venue for our workgroups to meet so workgroup leads should submit your request as soon as possible. Please keep in mind that there are no guarantees as space is limited. If your workgroup is planning on meeting at the Collaboration Summit please email me with the following information: 1. How many attendees for your workgroup session? 2. How much time will you need (N hours, 1/2 day or 1 day)? 3. Are there any technical requirements (projector, etc.)? If you have any questions please don't hesitate to contact me. Thank you. Cheers, C. -- C. Craig Ross Community Relations Manager The Linux Foundation +1 613 220 8998 http://www.linuxfoundation.org/ ___ Desktop_architects mailing list desktop_archite...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
Re: [OpenFontLibrary] font face firefox friendly?
Hi, everyone,
It would be nice if there were a way to query the browser (using
Javascript) about whether web fonts are supported or not. If that
were possible, then a web site like the new OFLB site could
dynamically show the web font preview when supported, and hide it from
view when not supported.
The Javascript would be trivial to write but my investigation so far
has not revealed any way of detecting web font support.
It is a common best practice principle when coding in Javascript
nowadays to check for the existence of certain properties. If the
property exists, then we can exploit the functionality whose presence
is implied by the presence of that property. If not, we can code
around it.
So perhaps we need to encourage the browser developers to expose a
public property, or document such if it already exists:
if( thisBrowser.supportsWebFonts ){
myWebFontDiv.style.display=block;
}else{
myWebFontDiv.style.display=none;
}
While I agree that the new OFLB site needs to rally toward the future,
unfortunately it looks clunky to say The text to the right should be
rendered in Font_ thanks to web font linking with @font-face. If
you see a monospace font, your web browser probably does not yet
support this new web technology.
On my laptop, I see DejaVu Mono Sans used in FF 3.0.5 for the
unsupported @font-face preview. The problem is, unless I look very
closely, I might actually think that I *have* got a preview of
Font_xxx --especially if Font_xxx is some kind of sans serif font
(like Puritan, for example)!
If someone on this list has any ideas on how to check for @font-face
support using Javascript, please let all of us know about it.
- Ed Trager
On Tue, Jan 6, 2009 at 4:00 PM, Dave Crossland d...@lab6.com wrote:
2009/1/6 fontfree...@aol.com:
Dave Crossland wrote:
FF3.1
So...you are focusing quite a bit of the new site on a feature not present
in MSIE, and only present in a beta version of Firefox. Hopefully
more browsers will support this in the future
MSIE has web fonts for its DRM format, which the W3C has rejected, so
no one else will ever support it. So we have to just wait for IE to
support non-DRM formats.
Opera's latest beta has support. Safari ships with support for nearly
a year. Chrome is rumoured to have support.
Web fonts is coming.
Re: [OpenFontLibrary] Stats for openfontlibrary.org
In my opinion, Alexa rankings don't mean anything unless a web site is in the top 100 or top 1000. After that, it is better to just look at the number of unique monthly visitors and track whether that is increasing or decreasing from month to month. For openfontlibrary.org, we don't expect the site to become popular until after the first phase of revisions and improvements are complete. If we then get some good press, the numbers will increase of their own accord over time. MSIE7 ... I'll refrain from commenting on that one. - Ed The stats for openfontlibrary.org seem not to work in MSIE 7: https://awstats.osuosl.org/list/openfontlibrary.org The stats are interesting, but also compare the Compete.com rank for openfontlibrary.org: #448,339, the Alexa Rank is: #643,978 Quantcast says not enough info. Openfontlibrary isn't exactly a hugely popular site, according to those 3rd party stats.
Re: [OpenFontLibrary] Should we (via moderation) accept all Free Software licenses?
Hi, Dave, On Fri, Nov 14, 2008 at 6:59 AM, Dave Crossland [EMAIL PROTECTED] wrote: It seems fonts developed in sourceforge like systems may not be able to support font linking at all, or only from their own sites. So, as policy, should we (via moderation) accept all Free Software licenses? Ed Trager: Yes. Question: Are all of these licenses OSI-recognized? Maybe we could have OSI-recognized license tags in one color and non-OSI-recognized tags in some other color or something like that? I'd like a show of hands - Please reply with your name and then yes or no - we can then debate the nos :-) Dave Crossland: Yes -- Forwarded message -- From: Ben Laenen [EMAIL PROTECTED] Date: 2008/11/11 Subject: Re: [DejaVu-fonts] Open Font Library wants to host your fonts for @font-face web To: [EMAIL PROTECTED] Cc: Dave Crossland [EMAIL PROTECTED] On Tuesday 11 November 2008, Dave Crossland wrote: Hi! Last week, Hendry asked on IRC if the DejaVu TTF were on a central website so that they would be easily linkable via @font-face CSS. Nope, sourceforge doesn't allow direct linking of files (it can only go through their file release system), so we need another location like OFLB. btw, wasn't there a built-in restriction for font linking in the browsers that support @font-face which limits font linking to the same domain as the webpage? Ben -- Forwarded message -- From: Dave Crossland [EMAIL PROTECTED] Date: 2008/11/14 Subject: Re: [DejaVu-fonts] Open Font Library wants to host your fonts for @font-face web To: Ben Laenen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 2008/11/11 Ben Laenen [EMAIL PROTECTED]: btw, wasn't there a built-in restriction for font linking in the browsers that support @font-face which limits font linking to the same domain as the webpage? Firefox has this, and sites must configure their HTTPDs if they want to allow cross-site fonts. OFLB will do this as soon as FF implements the feature (currently its turned on and can only be turned off by users configuring FF to not do it always, but thats because its in development)
Re: [OpenFontLibrary] Site statistics
Hi, Dave Ben, I got the keyTreeMap class needed for the virtual keyboard integrated and working today. Now it needs testing! If you and Ben want to test, that would be a great help too. Of course I will also do a lot of testing myself. Testing of complex key maps is what is really needed. Any keymap that requires entering 2 or more keys before arriving at a mapping is complex by definition here. So French and many of the other European key maps are in fact complex. For example, in the French keymap, you must enter E$ (2 keys) to get €. Maps where entering one Qwerty key maps to one target letter are not complex. For example, the Thai key map is not a complex map, because there are only 1-to-1 mappings. Using French as an example, what is supposed to happen is this: * If you type a c, the background changes color while waiting for additional input because the virtual keyboard will wait to see if you type c; for c-cedilla. * If you don't type ;, then the background reverts to white because it is no longer waiting for follow-on characters. * If you then type o followed by e, you get œ. Background color should actually change after the o, but doesn't -- must be a bug, but at least the mapping works correctly. * If you type u, the background changes because you can have u with umlaut or u with a hat (^) in french, so it waits to see what you type next. * if you type an r, then you will have arrived at the french word cœur. * So far, this is no different than what I had working a few days ago, except for the color. But now really complex maps like Devanagari should also work correctly and they definitely did not before. What makes Devanagari and some others really complex is that you can have 1-to-1, 2-to-1, 3-to-1, 4-to-1, 5-to-1, and maybe even greater n-to-1 mappings all in one key map. Maps like Devanagari are the ones that really require careful testing: http://eyegene.ophthy.med.umich.edu/gci/keyboard.php Also, do you think having the background change color to indicate that the keyboard is waiting for more input is a good idea or not? Let me know if you uncover strange bugs. Best - Ed On Thu, Nov 13, 2008 at 6:18 PM, Dave Crossland [EMAIL PROTECTED] wrote: Hi! We now have site statistics! https://awstats.osuosl.org/list/openfontlibrary.org Search keywords are interesting: https://awstats.osuosl.org/reports/openfontlibrary.org/2008/11/awstats.openfontlibrary.org.keyphrases.xml As are referrer pages: https://awstats.osuosl.org/reports/openfontlibrary.org/2008/11/awstats.openfontlibrary.org.refererpages.xml :-)
Re: [Openfontlibrary] design service
Hi, Jeremy, Others on this list may provide you with other answers. So please accept my suggestion as just one of several possibilities: As people begin uploading fonts, we discover some Latin fonts that contain not much more than basic Latin A-Z. To make these fonts really usable, it would be great if knowledgeable type designers helped out by adding the basic accented Latin letters required for pan-European usage first, and eventually an even larger set of Latin letters needed for additional Latin-based orthographies, such as Vietnamese, some of the American Indian language orthographies, and various African language orthographies. Another problem we may see is that even in OpenType fonts with kerning pairs, kerning pairs may only be present for the basic Latin letters, and not yet for the extended and accented Latin letters. So, depending on your level of experience, helping to fill out some of the existing fonts which appeal to you stylistically by adding accented and extended Latin glyphs, or by adding OpenType kerning features, may be a fairly entertaining way to get your feet wet initially. Best Wishes -- Ed Trager On Wed, Nov 5, 2008 at 11:10 AM, jeremy schorderet [EMAIL PROTECTED]wrote: hello, i am jeremy. i am a graduating student in graphic design in ECAL/switzerland. i have a little experience in type design. i would like to participate in the free font project what kind of font is most needed? hope to hear from you soon! jeremy ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] Non-Copyleft Openfontlibrary
Hi, Chris, Releasing a font under GPL or OFL license simply ensures the font can freely be used or modified by anyone and that no one can claim proprietary or commercial rights. If somebody does want a similar font to sell under a commercial license I'm perfectly willing to develop one for them for a fair price. Regarding no one can claim proprietary or commercial rights, I believe that is actually not quite the case under U.S. copyright law, as I understand it. As the original font author, I believe that you yourself have the right to sell your own font under as many different licenses as you want, commercial as well as FLOSS. Dual Licensing appears to be becoming fairly common in the FLOSS software world. Commercial entities often ask for a commercial license from FLOSS vendors because their lawyers like that better, I guess. Maybe it is the liability thing -- a commercial entity does not want to be accused of stealing someone's software or font, open source or otherwise, so they want to negotiate payment for use. So you actually don't have to develop a separate font -- you can use the same one you have already developed and sell it if you have buyers. For something like Jomolhari, I'm sure there is a market. Best - Ed ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] Non-Copyleft Openfontlibrary
Hi, FontFreedom, ... but I really want to have a non-copyleft openfontlibrary. Why? If we are not using copyleft licenses, what are you proposing to use in place? The whole reason for copyright law is to provide legal protections to authors of creative works, is it not? We now have enthusiastic communities of authors who recognize the value of giving back to the community, of sharing and remixing creative works. Licenses like SIL's OFL license for fonts have been designed specifically to help these authors protect their works so that they can do what they really want to do with them -- share them with the community! The right to share a work with others is just as much a legal right as the right to not share a work. The license makes this clear. And, BTW, the original author of a work is, at least under U.S. law as I understand it, free to release his or her work under as many or as few different licenses as s/he wants. So, for example, I could release an original font creation under OFL for the community to use, and still sell it under a commercial license for customers who may want some form of paid support or other service in return for payment. So licenses like the OFL provide clarity in terms of what authors want to allow or disallow. Public Domain on the other hand seems to me very fuzzy and unclear. What legal rights are reserved or not reserved? It's not clear to me. What are the author's wishes? Heck, who even *is* the author of a Public Domain font? Maybe if we knew who the author or authors really are, we would find out that they don't want their fonts under Public Domain once they recognize the advantages and legal protections that copyright law is supposed to provide. I therefore personally think that Public Domain should be discouraged. I certainly would not put anything I created under Public Domain. I would much rather put it under a license that makes it very clear that I want to share my work with the community. - Ed Trager ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] ccHost compression
Hi, Brendan, The PHP getId3() library is at http://getid3.sourceforge.net/. It might be worth looking into how to expand this library to recognize the TTF and OTF file headers, perhaps? The idea here seems quite similar to what the *Nix file command does. If someone were to look at the *nix file command source code, I bet you could fairly easily find a reference to the magic file header bytes that are used to detect TTF/OTF files and then add this to the getId3() stuff, assuming that getId3() is well-written. - Ed On Mon, Nov 3, 2008 at 2:06 PM, Brendan Ferguson [EMAIL PROTECTED] wrote: Could you point me to the page for this script? I would like to read more about it. ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] ccHost compression
One can always change a file name extension to something else, so testing against the file extension is probably not useful. PHP's $_FILES['userfile']['type'] will indicate the file's mime type if provided by the browser, but I don't know how browsers determine the mime type for uploaded files. The *nix file command reads the file headers and determines file type based on the pattern of bytes in the headers of files -- that is the most reliable way to do it. But again, I don't know if browsers use a similar method or not. - Ed I think a exclude list is better than an include list - that is, we should exclude files with .exe .php and so on, and include any files not matching this ban-list. ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] typography.js from http://typeface.neocracy.org/
I agree with Chris 100%. When I took a look at the http://typeface.neocracy.org/ project and code, I was surprised at all the work they had put in to it. One problem with this approach is that it is so temporary -- as soon as @font-face becomes more widely supported, their solution will be largely obsolete. The other and bigger problem, as Chris pointed out, is there is no support for complex text layout. So they have all of this nicely written code with complete workarounds for both CANVAS and VML, and perhaps one year from now it will remain largely unused. - Ed On Sat, Nov 1, 2008 at 12:19 PM, Christopher Fynn [EMAIL PROTECTED] wrote: Dave Crossland wrote: Do you think _not_ supporting things like that .js will help speed @font-face adoption? As much as possible, I'd like to see efforts *focused* on getting widespread support for @font-face. As I see it partial solutions can remove some of the pressure for a more comprehensive solution. I'm also not very keen on any font linking and embedding method that doesn't support the needs of users of non-latin scripts - and in particular the needs of users of complex (e.g. arabic indic) scripts. IMO, in this day and age, any font architecture which doesn't take account of complex scripts is broken. - Chris ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] The Next Version of OFLB
Hi, Dave, I took only a quick look at the TODO wiki page you mentioned: Default tags for upload pages- do we want more than: african, arabic, asian, cyrillic, fantasy, latin, monospace, sans_serif, script, serif, symbol Yes. I'm not sure what default tags for upload pages actually means, but I think the list of categories is not yet completely thought-out ... One question I have is will it be possible to have multiple tags on one font, say if I want to upload an African sans-serif font? For the geographic categories, I would have something much more along the lines of what I have got on http://eyegene.ophthy.med.umich.edu/NewUnifontDesign2/ (which, for those who haven't seen this yet, is an incomplete revision of my unifont.org font guide): * The Americas : Fonts for Indigenous American languages : Includes Latin, Cherokee, and Unified Canadian Syllabic orthography fonts. * African: Includes Latin and indigenous non-Latin orthography fonts. Since Arabic is used extensively in North Africa, a note alerts users that Arabic fonts are included in the Middle East section. * Middle East includes at least Arabic, Hebrew, and Syriac. * Europe has Latin, Latin Greek, LGC, Armenian, and Georgian sub-categories. * Central Asia has Tibetan, Uyghur (which is really an Arabic orthography), and Mongolian. It could also conceivably have a Cyrillic sub-category. * South Asia would be for the fonts covering the major orthographies of India. * Southeast Asia covers the many Indic-derived orthographies, as well as Latin-based orthographies such as Vietnamese * East Asia: Chinese, Japanese, Korean, Yi. I won't elaborate on the style categories at this point -- those may also require more thought and additional categories. the file itself). Something like: url(http://openfontlibrary.org/people/benweiner/2.0/Puritan_Regular.otf) url(http://openfontlibrary.org/people/benweiner/Puritan_Regular-2.0.otf) For the URL format, should it not be something more like the following instead?: http://openfontlibrary.org/people/benweiner/Puritan_Regular/2.0/Puritan_Regular-2.0.otf - Ed ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] TextLayout summit links + text Rasterization article
On 7/9/07, Nicolas Spalinger [EMAIL PROTECTED] wrote: Hi everyone, In case you haven't seen it yet, the papers/slides of the TextLayout Summit (along with recordings) are available on http://unifont.org/TextLayout2007/ Except the video is not ready yet. We have video for all of the afternoon discussions and will get this up as soon as possible. Best - Ed And this article on Text Rasterization has some useful ideas: http://antigrain.com/research/font_rasterization/index.html Bye, -- Nicolas Spalinger http://scripts.sil.org http://pkg-fonts.alioth.debian.org/ https://launchpad.net/people/fonts ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] Re: NEW FEATURE: Open Font License 1.1 Support!
Hi all, IMHO something like Ed's font playground technologies would be very cool: http://retina.ophthy.med.umich.edu/fontplayground/ I've just recently been looking at Cairo and Cairo+Pango integration and I think I will in the very near future be capable of providing a technically much cleaner and more sophisticated version of Font Playground. The current Font Playground backend on the retina URL is very much a hack of a bunch of stuff --good for proof-of-concept but the code is *not* pretty to look at. A Cairo+Pango version of FontPlayground could provide a very nice solution for the backend. Just as in the current version of Font Playground, AJAX is a must on the front-end. I Just hope no one is in a great rush as my time is currently split among a lot of other projects. - Ed Trager Cheers! Jon -- Nicolas Spalinger http://scripts.sil.org http://alioth.debian.org/projects/pkg-fonts/ https://launchpad.net/~fonts ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary ___ Openfontlibrary mailing list Openfontlibrary@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
Re: [Openfontlibrary] looking for corefonts replacements, how to replace?, and site search
Hi, Denis, A good subsitute would have original designs for glyphs but the same metrics as the non-free font it aims to replace. The Bitstream Vera set of fonts actually have different metrics than the corresponding MS Core fonts, right? There was a post on the this list about somebody I think in Australia who has taken the Bitstream set and changed the font metrics to match MS Core font metrics. How bad is that, I wonder? How different are they? Also, has the Deja Vu project changed the overall font metrics at all, I wonder, to accomodate all of those extended Latin and other added characters? Many people are interested in the issue of document fidelity -- where, for example, pagination of a document does not change across OSes. Correct me if I am wrong, but I believe that there are some well-known commercial fonts that also have the same font metrics -but different glyph designs- as some other better known commercial fonts. Presumably the reasoning is the same: to allow drop-in substitution of the alternate font while still retaining document fidelity. I wonder who has solid information on this issue? Best - Ed Trager ___ Openfontlibrary mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
