IRC meetings/September 28, 2006
From DejaVu
Contents |
September 28, 2006
The DejaVu Fonts project would like to hear the view of the community on some subjects. That's why an IRC meeting is organized next Thursday September 28, at 18:00 UTC on the #dejavu channel on Freenode.
Topics will include:
Future license of DejaVu
What if Bitstream releases Vera under OFL? Should we follow as OFL seems to become the standard free font license? Do we keep our additions in public domain?
Future development process of the project
The project is heading for full Unicode coverage, but how will we approach that goal? What should be done to make sure DejaVu doesn't become a mismatch of glyphs? Should development be altered to maintain quality?
LGC and other derivatives of DejaVu
We currently ship the LGC derivative including only Latin, Greek and Cyrillic glyphs. Should we keep that one? Should we have other derivatives with glyph subsets? Is creating subsets a good idea? Fedora ships with DejaVu LGC, why? It has been said a few times that DejaVu should ship as a set of lots of different fonts for each script; do we want that; do we want to rely on FontConfig for correct font rendering?
Log of meeting
--> You are now talking on #dejavu
--- Topic for #dejavu is DejaVu fonts 2.10: http://dejavu.sf.net/ ; Unicode 5.0: http://www.unicode.org/versions/Unicode5.0.0/ ; IRC meeting on September 28, at 18:00 UTC
Topic for #dejavu set by eugen at Sun Sep 24 21:39:48 2006
ChanServ gives voice to moyogo
<eimai> moyogo: quickly created http://dejavu.sourceforge.net/wiki/index.php/IRC_meetings
<moyogo> eimai: great
<eimai> can you make the log afterwards, so it can be put on the wiki as well?
<eimai> moyogo: ^
<moyogo> ok, i'll save the log and do that
<eimai> moyogo: btw, was there anything said yesterday after I left that was important?
<moyogo> eimai: I don't think so
--> nim-nim (n=nim-nim@m37.net81-64-156.noos.fr) has joined #dejavu
behdad (n=behdad@lachesis.cs.toronto.edu) has joined #dejavu
<behdad> hey guys. seems like I cannot make it to the meeting today.
I just had this idea that I let out for discussion
* slef adds some links to ringtines to eimai's wiki page
<behdad> I think dejavu can use the same family name for different subsets. so you have a "DejaVu Sans" covering LGC only. another for Arabic, ...
<eimai> slef: you need a wiki account for that...
<behdad> if you install them all, you get them all. if you install LGC only, you get that...
--> yosch (n=yosch@lns-bzn-23-82-248-102-105.adsl.proxad.net) has joined #dejavu
<behdad> later ;)
<-- behdad (n=behdad@lachesis.cs.toronto.edu) has left #dejavu
<eimai> slef: and you get those accounts on request
<nim-nim> hi all
<eimai> no Med and no eugen today...
hi nim-nim
<nim-nim> eimai: you forgot to change the ##fonts topic back
<moyogo> behdad's idea is interesting
<eimai> ah, but moyogo did that
<yosch> hi everyone
<eimai> 5 minutes until breakdown
<nim-nim> moyogo: behdad's idea sucks
<nim-nim> :)
<eimai> I was hoping for more dejavu developers, or how would we discuss the license part...
<nim-nim> it only works in isolation when you never exchange documents with someone else
--> eugen (n=eugen@cd1.cd.TU-Cottbus.De) has joined #dejavu
--- ChanServ gives voice to eugen
<moyogo> nim-nim: i guess the trick would work one-way
<nim-nim> if you do write documents or web pages you're going to have big surprises if everyone has different fonts under the same name
<moyogo> nim-nim: from LGC to *
<eimai> and it doesn't work like we would want: have the other scripts in dejavu installed as well, but don't use it with those fontconfig magical aliases
<moyogo> we should make a test with two fonts, one with just lgc and one with arabic, both called dejavu and see how it behaves
<eimai> moyogo: you're on ##fonts by any coincidence? maybe there are people there that may want to join
<nim-nim> if someones remind me the command to get super-powers i'll change ##fonts topic to what it should be
<eugen> nim-nim: / msg chanserv op
<eimai> it's /msg ChanServ op ##fonts
okay, so it's time apparently
welcome everyone to our first irc meeting
for people who don't know who is who, the obligatory introduction round :-p
* eimai is Ben Laenen - dejavu admin
eugen is Eugeniy Meshcheryakov
nim-nim is Nicolas Mailhot - Fedora Extras dejavu packager (and other peripheral stuff)
yosch is Nicolas Spalinger, SIL volunteer, OFL, Ubuntu fonts team - interested in collaborative font design
--> glasseyes (n=glasseye@193.1.233.114) has joined #dejavu
<eimai> hi glasseyes, join the introduction round
<yosch> hi glasseyes :-)
<glasseyes> hi folks, I'm Daniel Glassey, linux graphite porter with general interest in fonts, and volunteer for SIL (who produced the OFL)
but I guess yosch has already mentioned that ;)
* moyogo moyogo is Denis Moyogo Jacquerye - dejavu admin
--- ChanServ gives channel operator status to eugen
eugen has changed the topic to: DejaVu fonts 2.10: http://dejavu.sf.net/ ; Unicode 5.0: http://www.unicode.org/versions/Unicode5.0.0/ ; IRC meeting
ChanServ removes channel operator status from eugen
<eimai> no more people who want to introduce themselves?
<eimai> the topics we'll discuss today are at http://dejavu.sourceforge.net/wiki/index.php/IRC_meetings
--> UnNamed (i=500@16.Red-80-32-164.staticIP.rima-tde.net) has joined #dejavu
<eimai> let's first take off with what most people aren't interested in ;-) the license question about dejavu
the license right now in dejavu is the bitstream licesnse for what we forked from vera
<eimai> the arev license (which is almost identical to it, except for some name changes) for glyphs imported from arev
and everything else is public domain
<eugen> what advantages does OFL have?
<eimai> there has been a large discussion recently about getting free fonts under the open font license OFL
* slef returns. MJ Ray, debian and koha developer, gobo user, gnustep webmaster.
<eimai> there is also someone working on getting vera relicensed under OFL
eugen: big advantage would be working together more easily between fonts
when everyone shares the same license
for the OFL itself, see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL
<slef> Biggest problem is that OFL hinders font self-configuration and compatibility, but I'm hoping that yosch will fix that in a redraft.
<yosch> eimai: Simos from GNOME is the contact for the upcoming vera release.
<eimai> ah, it was Simos who was doing it
<moyogo> yes, too bad he's not here
<nim-nim> :( simosx ++
<eugen> do we need to wait for Bitstream to relicense fonts?
<eimai> I've mentioned previously that I'm not happy about the current license in dejavu (I don't like the arev license part in it)
<yosch> slef: yes, the new draft claryfing the non-coverage of configuration file is underway
<eimai> eugen: yes, we can't move to OFL if vera isn't under OFL
<slef> yosch: can it be more general than a specific configuration-file-exception?
<yosch> I know Simos was away and fairly busy but I'll send him a little note to Simos to ask where things are wrt to Vera
<slef> yosch: as in, it may not claim to be the Reserved Font Name fraudulently, but may mention the Reserved Font Name in description or partial compatibility?
<yosch> eimai: yes, you don't want to end up with a list of concatenated licenses :-(
<eimai> when I mentioned on the mailing list that we maybe should have everything under OFL, remarks were made that they want to keep the public domain part, was that you eugen?
<slef> eimai: are Vera's terms OFL-incompatible?
<eugen> eimai: no, I do not think so
<eimai> eugen: then I should do my homework better :-p
<eugen> eimai: but having additions in public domain would be good
<eimai> are there people online that have arguments why they want to keep public domain?
<eugen> eimai: it is easier to relicense font ;)
<slef> I can't see what you gain trying removing work from the public domain.
<yosch> slef: the OFL makes the vera mechanisms reusable: non-project specific, non-organisation-specific
<nim-nim> from a packager POW single universal license=good, multi-licensing=bad
<slef> Things from the copyright-PD can be relicensed as you wish.
<eimai> or if someone can clarify what it means exactly that a letter is under arev license, and that a slightly modification of that letter is public domain
<moyogo> as long as the glyphs are not derived from the original vera I don't see why new ones can't be in PD, it's compatible with either BVL or OFL
<eimai> eh, vera license I mean
<eimai> moyogo: but how do we keep those apart?
<slef> yosch: the OFL mechanisms look like compatible with the Vera licence => you could license a font derived from Vera under OFL as long as its name contains neither Bitstream nor Vera.
<slef> eimai: why do you need to keep them apart?
<moyogo> eimai: right now it would pretty much be LGC must be whatever Vera is, and everything else can be PD
<eimai> we should have a way to state very clearily what is PD and what not
slef: legal issues, I guess
<slef> eimai: list the glyphs in each class?
* slef contributes to debian-legal but INAL
<moyogo> if they are in PD, it means people can reuse them in fonts with different licenses
<eimai> also, how do we handle other contributors coming up that want to add a new script, but not in PD
<nim-nim> My personal POW is tracking PD and being careful to avoid contamination is a lot of work for nothing
<slef> actually, you could just say "the entire font is under the OFL, but glyphs NNNN-MMMM are in the public domain"
<moyogo> if they are in OFL, they must be reused in OFL only
<yosch> How do you convince designers to release directly into the PD? how do you maintain artistic integrity with a font under PD? what about name collisions?
<nim-nim> what PD wins us exactly ?
<moyogo> PD is PD, OFL is copyleft
<slef> PD wins you more freedom. Let the designers choose how much they're willing to give.
<moyogo> slef: they actually give it all away with PD
<slef> One note: PD is not simple everywhere. There's a thread in the Sep 2006 debian-legal archive about it.
<yosch> moyogo: yes it inherits the license if you branch, but then it makes it easier to exchange patches with other projects with a common well-understood license
<nim-nim> slef: then let one contributor stand for PD, if no ones interested that's a lot of paperwork for nothing
<slef> yosch: moral rights and trademarks exist independently of copyright for fonts, don't they? So, you can maintain artistic integrity and namespace.
<yosch> moyogo: indeed: "giving away" is not really how many designers feel like AFAIK
<moyogo> yosch: we've actually had a different experience with our designers
<slef> nim-nim: uh, PD is zero paperwork. You don't *have to* document which bits came from the PD, although I think it would be nice.
<yosch> moyogo: OK, but I doubt most AtypI members would think like you guys
<moyogo> lots of our designers just want to "give away"
<slef> nim-nim: for fonts under the OFL, you still need to track who holds copyright to which glyphs.
<moyogo> yosch: yes, they have different motivations
<eimai> right now we have tavmjong bah from arev fonts that don't want his glyphs under PD, we had a contributor for Georgian script that wanted it to be under BVL, so it's not like all developers want it under PD
<nim-nim> slef: PD is not sero paperwork. Unless you're 100% PD you have to spend a lot of time being real careful PD glyphs are not modifier reusing non PD parts (and so on)
<slef> nim-nim: or get written/signed copyright assignments to some trusted holding company.
<yosch> slef: or a non-profit. Doesn't have to be a company.
<moyogo> everything under OFL seems like the easiest solution
<nim-nim> +1 KISS
<slef> nim-nim: huh? You can do anything with stuff from the PD, including modifying with non-PD parts. It just means the combined work isn't in the PD.
<slef> -1 until OFL is revised to fix the Reserved Font Names
<slef> yosch: non-profits are a type of company.
<eugen> -1 too
<moyogo> we'll have to wait for Bitstream and Arev change of license first anyway
<nim-nim> slef: so you have to track interaction between PD glyphs and the rest of the font, so the PD range you anounce is the actual one
<moyogo> +0 either way (marked PD with OFL or just OFL, fine either way for me)
<slef> nim-nim: you have to track interactions anyway, unless everything has its copyright held by the same person
<eimai> do we already take any action right now to get the arev glyphs under the BVL? or do we wait until BVL becomes OFL (regardless if we keep PD part)
<eimai> yes, same opinion as moyogo for me, I can live both with or without PD part
<nim-nim> slef: if everything is under a compatible license, and the license allow modifications, you have nothing to track
<yosch> slef: the RFN mechanism is fine: you have Jim Getty's reply: it is a desirable feature. It's the font software definition we'll fix to not be misunderstood as covering fontconfig configuration
>eimai< hehe we're bad dictators :)
<eugen> nim-nim: you need to ask each copyright holder if you want to change license for example
<slef> nim-nim: you still need to track the copyright holders. Please, go take a course on copyright before you make trouble.
<yosch> slef: you don't measure trust for for-profits and for non-profits in the same way
--- Topic for #dejavu is DejaVu fonts 2.10: http://dejavu.sf.net/ ; Unicode 5.0: http://www.unicode.org/versions/Unicode5.0.0/ ; IRC meeting
Topic for #dejavu set by eugen at Thu Sep 28 20:05:42 2006
#dejavu :You need to be a channel operator to do that
<slef> yosch: then self-configuring fonts cannot be entirely under OFL, which sucks, for reasons mentioned here already this evening.
>chanserv< op #dejavu moyogo
--- ChanServ gives channel operator status to moyogo
moyogo has changed the topic to: DejaVu fonts 2.10: http://dejavu.sf.net/ ; IRC meeting http://tinyurl.com/rjaup
<nim-nim> slef: don't assume copyright law in my part of the world is 100% the same as in yours
<slef> nim-nim: if your country is in the Berne Union, you should track copyright holders.
<yosch> slef: self-configuring fonts? again the OFL is not intended to cover fontconfig configuration files
<slef> yosch: what is the point of requiring font tarballs to be under OFL+GPL or OFL+MIT/Expat?
<slef> Also, I'm pretty sure people would mistakenly put the entire thing, including config, under OFL. If OFL says it cannot cover config, then we have an All Rights Reserved config by default. Please, fix it.
* slef waits for moyogo to tell him to stop ;-)
<yosch> slef: what?
<slef> yosch: you say OFL will not cover font config files?
<yosch> it's up to the designers themselves to decide if they want to dual-license, I don't know where you're reading this "requirement"
<moyogo> we'll have a formal vote with all the authors to chose between full OFL or OFL with PD parts, when Bitstream goes OFL and after OFL is revised :)
<eimai> okay, we seem to move a little away from dejavu license discussion now, so let's move on
<yosch> eimai: yes
<slef> not dual-license, two license
ok
<moyogo> future development process is the next topic
<yosch> eimai: we have to see what happens with Vera
* eimai is handing over moderator stick to moyogo
<moyogo> we've added a lot of scripts recently
and there are more in process
<eimai> basically, how will we be able to maintain a font with more and more glyphs?
<moyogo> is our current work process going to scale with time/
?
<slef> Can you outline how it is currently done, please?
<eimai> slef: right now, we have everything in one font file for each font like dejavu sans bold etc
<eimai> that has the issue that those files are becoming extremely big for example
<moyogo> slef: devs submit patches onces they feel it is ready for inclusion
<eimai> and that glyphs with no unicode points are becoming a huge unordered pile
<moyogo> but we've also had a hebrew branch recently
<slef> so you could split the big font file into a sequence of patches to an empty font file?
<eimai> it has been coined in earlier discussions that we maybe should split everything up, stepan was admin back then and wiped that idea from table, but maybe we should revisit the idea
<eugen> no
<nim-nim> -10
<eimai> I only mean in development cycle
I don't mean in the files we're releasing
(that's the next discussion :-p )
<nim-nim> fine then :)
<eimai> right now, the development files for sans are already > 2 MB each
<nim-nim> the problem is to get meaningful testing, when everything is split/branched and half a person uses/works on each bit
<slef> it seems obvious the big file and desirable subsets should be distributed, but it seems awkward for development
<moyogo> it seems awkward, but what we're doing right now is already distributed, at least until merged in the main dev file
<nim-nim> how do you define desireable subset?
<eimai> I'd like to know if some people see clear issues that would have to be dealt with when development files are split up into some scripts
<moyogo> eimai: the merging part :)
<eimai> or if people are really against that of course, then they can mention that too :-p
references may be another
but we should keep LGC + symbols + extension etc in one file
arabic and laos stand on themselves
they could be split of quite easily
without referencing hell
<slef> nim-nim: what people ask for.
<nim-nim> slef: people all ask for a split, not of them agree on the same one
none
<moyogo> actually fontforge can merge fonts really easilly, but hinting might be a problem
<nim-nim> eimai: are you tring to do some sort of manual branching, reduce download times of what?
<eimai> nim-nim: keep sfd file sizes in manageable limits, and keep the font maintainable
<eugen> moyogo: probably no only hinting but also substitution, etc
<eimai> nim-nim: when laos, thai, khmer etc would all be added to the same font file, all ligatures etc would become not maintainable I think
<nim-nim> if it's download time an rsync-enabled download server would probably work better with less manual work
<eimai> all separate sfds should have same cvt, prep and func values for hinting of course
may be hard to sync when changes are made to those
anyway, since we don't have many developers online right now, we should bring up this issue on the mailing list again maybe
<glasseyes> can those values be stored and read from somewhere shared? (I know nothing about it so just guessing)
<eimai> glasseyes: maybe moyogo will propose xgridfit now :-p
<moyogo> :-)
* yosch wonders if svk (distributed svn) should be investigated for a possible solution
<-- zwnj has quit ("ZWNJ.org")
<eugen> yosch: you can use svk now
I see no problem with that
<moyogo> the other option would be to have a longer dev process before inclusion in the public release
<glasseyes> ok, I need to go to dinner now, but just to say for the 3rd item, release big fonts if people want them, but some kind of split fonts is defintely needed IMHO
<yosch> eugen: I'm thinking it should make the merging easier: one branch for script group maybe?
<eugen> yosch: no, it will not be easier, belive me, I worked on hebrew branch
<moyogo> svn branches for all the new scripts could help too.
<nim-nim> right, branching and splitting are different things. I don't think anyone would object to more branching
<-- glasseyes has quit ("Leaving")
<eugen> nim-nim: it is hard to have all of those mergeable
<yosch> eugen: OK I see
<eugen> there are alot of conflicts
<moyogo> eugen: merging with fontforge or svn?
<eugen> svn
<nim-nim> I don't see how splitting the files would lower the conflict rate, unless the sfd format sucks big time
<eimai> if we split up development sfd, we shouldn't use branches, but just different directories in the same branch I'd say, and a nice script to put them together
<slef> make dist ;-)
--> behdad (n=behdad@lachesis.cs.toronto.edu) has joined #dejavu
<yosch> having a stable and unstable branch is desirable IMHO
<behdad> is the meeting over?
<moyogo> behdad: nope, we're still at topic #2
<nim-nim> behdad: no, we're at the splitting part (not the one you think of;)
<behdad> ah
;)
I have a very loose presence at the moment. Will check the logs later
<moyogo> a cleaner stable branch would be a good idea, but the merging issue still remains
<eimai> yep, stable vs unstable development has big issues
also, what would be stable and unstable?
personal opinion is that because of the fact that it's almost not doable due to svn conflicts etc it's not worth to make unstable and stable branch at the moment
developing the fonts should stay fun for our developers, it shouldn't be fixing conflicts all the time
<slef> I would expect stable to be 'no new languages/ranges, but serious errors in current ones get fixed'
<moyogo> a stable release could be just for major changes, like when new scripts are added and hinted (to a useable degree)
<slef> and then periodically integrate whole new scripts(not ranges...)
<moyogo> slef: yes :)
<eugen> moyogo: do we have any new scripts hinted to useable degree?
<nim-nim> IMHO dejavu should have:
<nim-nim> – stable : last release, only touched if showtopper problem
– devel : what people are working on for next release (stuff which is reasonably expected to be dogfoodable by then)
– "topic branches" : branches where people work/test a new block, but can not be merged in devel now
<slef> nim-nim++
<moyogo> eugen: hebrew went from brand new to a useable degree thanks to your hinting, no?
<eugen> moyogo: only Book
moyogo: and not dotted Hebrew
<eugen> probably
<moyogo> eugen: so useable would include Book and Bold?
<yosch> nim-nim+++
<eugen> until someone explain how to hint Oblique
<moyogo> eugen: :)
nim-nim: that's sound good ++
<eimai> nim-nim: yep, branches like that are a good idea, if it's workable, but still have to get convinced about that :-p
<moyogo> so the work process wouldn't be that different from the current one, just different names and version numbers :-)
<eimai> okay, we should put forward this issue again on the ML
<eugen> eimai: we well have long development cycles then, just like Debian
<eimai> eugen: I'd say, keep each realease each month, but release stable and unstable?
only more files to release...
<eugen> eimai: yes, maybe that will work better
<eimai> okay, we should move on to topic 3 I think
<eugen> but I'm not sure how to synchronize files
<nim-nim> eugen: no you won't, devel is defined by your release cycle duration, not by the stuff people are working on long-term
<moyogo> maybe stable could be less often if there's not fix :)
<eugen> nim-nim: I was talking about stable
big changes to stable
<moyogo> fixes shouldn't be too much trouble for stable releases
and dev should become "stable" after a while
<nim-nim> IIRC, the project only needed to do a bugfix release once
<eimai> the infamous 2.4.1 release :-p
<moyogo> yeah :)
<eimai> the world was never the same after that one...
<moyogo> so should we move to a dev/stable release cycle and on what time cycle?
<nim-nim> one month please :)
<moyogo> even for stable?
<nim-nim> especially for stable :)
<moyogo> it doesn't make sense :-/
<eimai> moyogo: why not? it may not give the impression to be stable, but I want fixes out as soon as possible for a font
<eugen> nim-nim: stable should be bug-free ;)
<moyogo> we can't release stable every month if all the changes are just in dev
<nim-nim> moyogo: I want dev = changes which will be ready by next month
<moyogo> nim-nim: i'm confused
oh... ok, got it
<eugen> nim-nim: then there is no point in having stable
<eimai> anyway, we're discussing this topic for a long time now already, so we should move on
<nim-nim> stable is for changes which can not wait one month
<eimai> so let the "to split up dejavu or not" discussion begin...
<moyogo> yeah we can further discuss this on the list or another meeting :)
* eugen does not see any advantages to have different fonts for each language
<eimai> I don't think that topic needs an introduction...
<nim-nim> users and distros like fast clockwork cycles, what they *don't* like is half-cooked stuff being released as stable. Hence the 3 layers : stable, devel and long-term stuff
should we wake up behdad?
<moyogo> nim-nim: yeah but 1 month seems to short for well-cooked (for new scripts and things like that)
<nim-nim> moyogo: that's why new scripts get their own topic branch till they are a the stage they can be finished by next monthly release
<eimai> okay, so dejavu will keep getting more and more scripts, should we release everything as one font, or are there people with good arguments why taht shouldn't be the case?
<eugen> nim-nim: as I said that is not easy
<moyogo> nim-nim: ok, so the can be in their own branch as long as need, 1 month in dev for cleaning and then in stable
<nim-nim> eugen: sure. But mixing stuff with different timelines in the same branch makes it even harder
<nim-nim> moyogo: right. And each new script has it's own branch so one can not block the others
<eugen> eimai: what is adnvantage of splitting? that you'll need to specify different font for each script?
<moyogo> nim-nim: yup, we'll have to work it out
<eimai> eugen: that's what some people propose we should do anyway
those people only have to wake up now
<nim-nim> :)
<eimai> ping everyone against one big font file with all scripts ;-)
<moyogo> one advantage of splitting is smaller fonts files ;)
<eugen> then, why do we need DejaVu at all?
<nim-nim> many smaller font files
<nim-nim> bigger disk use
<moyogo> eugen: we keep a "compatible font style"
<nim-nim> bigger memory use
<nim-nim> bigger user-barin use (think long font lists)
<nim-nim> brain
<eimai> dejavu wants to deliver a unicode font with compatible styles for each script
* eugen wants one font
<eimai> fontconfig people don't seem happy with it
<eugen> per style
<moyogo> the other problem with one font is the current lack of support for BASE table, which is necessary when script have different metrics
baseline or minmax
<eugen> moyogo: than *that* should be fixed
<eimai> it has been proposed to allow aliases in fontconfig to not take into account certain fonts for certain scripts, but don't know if they made any decision about that already
<moyogo> eugen: totally agreed :)
<yosch> yes, harmonizing different styles is hard
<moyogo> it's easier with Sans though
<nim-nim> and anyway French people want latin with slash 7, balkanic people russian cyrillic with a few glyphs changed, you can't sanely work this out by splitting files
<behdad> nim-nim: actually from Fedora Core's point of view, we prefer a longer release cycle. We probably are going to not push some of the monthly releases. Pushing 2MB of updates to every client every month for a few added glyphs is not very user friendly.
<nim-nim> behdad: I was thinking about rawhide, not FC updates
long upstream release suck, you always end up shipping a snapshop or pre-release under user pressure
with fast release cycle you're always at worst one release away from upstream when the distro ships
<behdad> nim-nim: rawhide is not very interesting anyway
<nim-nim> behdad: it is if you want a stable Core
<behdad> nim-nim: we do push into rawhide
nim-nim: even in freezes. for example I pushed 2.10 in fc6 yesterday
<eimai> mmm, I think we need people here that want to split the fonts up into different scripts, or this discussion will never happen
<moyogo> more people
<nim-nim> It seems no one wants the splitting here, so why not say we've reached a consensus?
<eimai> behdad: where's your split-fonts-up army?
<behdad> eimai: as long as there is a separate LGC, I'm fine :)
<eimai> nim-nim: hehe :-D
behdad: but at one point some users will complain, and we have to decide what we will do with LGC as well
<behdad> eimai: complain about what?
<yosch> actually the arguments for SIL font designers against the big font go like that:
You can't get all the Unicode glyphs in a font
<moyogo> yup
<yosch> Community development can become much more difficult
<eugen> yosch: that is ok
<yosch> Performance - with a number of very large font in memory the system will be slowed down.
<eimai> furthermore, right now alls fedora users will create documents with "DejaVu LGC Sans" as font name
which won't work with people with the full dejavu font installed
<nim-nim> yosch: the counter argument, of course is just to add new scripts till you've proved your point :)
<yosch> there are many regional variants that need to be taken care of
and the memory footprint
<eimai> behdad: say that some people would like dejavu armenian for example, or one of the other new scripts added
<moyogo> eimai: they have an alias in fedora
<yosch> nim-nim: :-)
<behdad> eimai: yeah, having separate ones is interesting of course.
<moyogo> having DejaVu Arabic, DejaVu Armenian, etc. along LGC is an option
<nim-nim> yosch: variants will always be easier inside a single font (once base and locl are done). You only need to provide alternatives for the few glyphs which do vary, not the whole unicode rande
<nim-nim> range
<eimai> moyogo: but we don't want to release 40 different fonts each month...
<moyogo> eimai: definitely not
* yosch points to Ed Trager's "Pan Unicode" article for a interesting analysis: http://unifont.org/fontguide/ (pan-unicode tab)
<yosch> nim-nim: and when the few glyphs are big blocks?
<nim-nim> yosch: so what ? will the block be any smaller if the files are split ?
splitting files means :
1. you draw the glyphs which are different
2. you re-create or duplicate the glyphs which are identical
single files mean : you only need to do 1.
<yosch> nim-nim: if the variation threshold is too high, IMHO it's desirable to have two different fonts: one with each style variation, which doesn't mean it can't have other common block copied over
<eimai> also, if we split the fonts up, we will depend on fontconfig for displying dejavu nicely, our windows users won't be happy with that
<nim-nim> yosch: splitting means you are relying on the user to sort the fonts. That's not simplifying, that means you move work your font engine should do to the end-user and the upstream project
<slef> gtg
<-- slef has quit ("thanks for all the fish")
<eimai> I have the impression this discussion won't really take off today, if we won't find some more people that share behdad's view quickly
<eugen> yep
<nim-nim> I think behdad has decided LGC is good enough in the short term
<eimai> I guess the announcement didn't reach them
<moyogo> i think both sides have valid arguments
we'll discuss this with people for the split pretty soon anyway :)
<eimai> yeah, I'm sure they'll turn up there :-p
but I wanted to have some rehearsal first...
anyway, I think we can close the meeting then, unless someone wants to really say something first
<yosch> I'm fairly sure there is a good solution ahead
<eimai> okay, so end of discussion then, thanks to everyone participating today
* yosch just wanted to mention that the AtypI conference is happening now see http://www.atypi.org/06_Lisbon
<nim-nim> yosch: if behdad manages to get BASE support in soonish, that'll be a reason less for manual time-consumong splitting
<yosch> and they will speak about open font design
<yosch> nim-nim: yes if the rendering stack helps it would be great
--- ChanServ gives channel operator status to eimai
<-- behdad has quit (Read error: 60 (Operation timed out))
<eimai> mmm, why can't I change the topic again?
<moyogo> /topic doesn't work?
<nim-nim> IMHO the FLOSS stack will be good enough soonish at the local level
<eimai> moyogo: no, it says "You must be a channel operator on #dejavu to do that."
>chanserv< access #dejauv list
<eimai> but I am
>chanserv< access #dejavu list
* yosch wants to congratulate the Dejavu team for their great work, thank you all for helping make the free desktop better :-)
<nim-nim> what will be a challenge will be to write the tools for the user to choose his prefered variants, and to publish these settings from one system to another
<eugen> eimai: maybe freenode do not support two operators?
<moyogo> yosch: thanks, and congrats for your spreading the gospel part ;-)
<eugen> ;)
<nim-nim> ie in a fontconfig world "Name" is an insufficient font qualifier
<moyogo> eimai: weird indeed
<yosch> moyogo: :-D
<nim-nim> thanks to the team
do roll over the splitters in Boston :)
<moyogo> nim-nim: that's a problem that needs to be solved on every platform
there is no typography markup language at this point
<nim-nim> moyogo: that's why I write it will be the real challenge
--- moyogo removes channel operator status from eimai
moyogo removes channel operator status from moyogo
ChanServ gives channel operator status to eimai
<eimai> ugh
<moyogo> it still doesn't work?
<eimai> no, /deop doesn't work for me either
<eugen> eimai: /msg chanserv op #dejavu -eimai
<moyogo> that's strange we have the same access points
--- ChanServ removes channel operator status from eimai
<eimai> aha, thank you eugen
