Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Le 2019-01-30 11:23, Nicolas Mailhot a écrit : Le 2019-01-30 10:32, Akira TAGOH a écrit : This would avoid collision between one and origins. and assuming that flatpaks can load config from host too, we could have: 10-salt.conf (from host): Note that the "id" attribute has special meaning and constrains in xml. I'm not saying it should not be used, but it will restrict future evolutions more than another choice. One of the constrains being it must be unique. So if you use id for salt, you effectively forbid the use of the same salt for two different elements. (of course one can cheat with non-conformant xml parsers, that restricts interoperability though). Regards, -- Nicolas Mailhot
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Le 2019-01-30 10:32, Akira TAGOH a écrit : This would avoid collision between one and origins. and assuming that flatpaks can load config from host too, we could have: 10-salt.conf (from host): Note that the "id" attribute has special meaning and constrains in xml. I'm not saying it should not be used, but it will restrict future evolutions more than another choice. -- Nicolas Mailhot
Bug#408939: FYI, on iceweaseling old standard
(07:59:29) nim-nim: btw pabs3, I've seen debian packaged old standard (07:59:42) nim-nim: upstream has asked me to iceweasel it 08:00 (08:01:50) pabs3: looks like we haven't uploaded it into debian proper yet (08:01:53) pabs3: whats the issue? (08:03:06) pabs3: nim-nim: ^^ (08:03:17) nim-nim: pabs3: just that upstream apparently did manuaml tweaking on fontforge output in proprietary tools (08:03:39) pabs3: yay (08:03:41) nim-nim: and thus feels a font rebuilt from source wouldn't 100% represent its design (08:04:05) nim-nim: and does not want to re-test with every fontforge release if the tweaking is still needed (08:04:44) nim-nim: so the author asked me to rename the font if I rebuilt it from source in Fedora 08:05 (08:05:17) nim-nim: and I put it on my backpile while thinking about a good iceweasel name (08:05:32) pabs3: ugh. can you send a mail to [EMAIL PROTECTED] explaining the issue? (08:05:39) nim-nim: or about good arguments to make upstream change his mind (08:06:05) nim-nim: pabs3: let me see if I have the original mail somewhere (08:06:27) nim-nim: I personnaly intend to go the iceweasel route when I find the time to look at it again (08:06:38) pabs3: ok (08:06:47) pabs3: ttf-oldweasel :) (08:07:21) nim-nim: pabs3: I was thinking about old standard iced (08:07:29) nim-nim: or something like that (08:07:38) nim-nim: but my naming skillz suck (08:07:38) pabs3: this is one aspect of the OFL I really *do not* like (08:07:57) pabs3: hmm (08:08:39) pabs3: shall I ask on #debian-devel? bound to get a few ideas from there (08:09:17) nim-nim: pabs3: sure (08:09:37) nim-nim: I didn't really tie this loose end so far 08:10 (08:10:07) nim-nim: and IMHO it's still worthwhile to check with the author if he likes the iceweasel name (08:10:26) nim-nim: maybe two distros asking for the same thing will make him change his mind (08:10:41) pabs3: aye -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Bug#408939: FYI, on iceweaseling old standard
Le vendredi 09 mai 2008 à 11:19 +0200, Nicolas Spalinger a écrit : BTW, I strongly disagree with choosing an offensive name for a renamed derivative. Bad form. IMHO this is not what this community is about. I didn't advise that seriously. Upstream requested a renaming when I asked its opinion about rebuilding from sfds, so renaming it is, and it'd better be the same for all the people that rebuild from sources. In in fact it made me put old standard on hold till I found a good name and/or argument to convince upstream to change its mind. A sane license is a good first step, the fully free sources and the fully free build path will stem from that (as some designers are now doing) but making them a strict requirement for everyone/everywhere is going to prevent *many designers* from joining our community. Another upstream argument was fontforge just changes all the time and he does not want to have to follow it closely. /me goes back the LGM talks. I'll report back to you guys about the stuff happening here around fonts. That would be nice. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Bug#457647: [DejaVu-fonts] Bug#457647: fontconfig-files of upstream sources are not in package
Le lundi 24 décembre 2007 à 14:43 +0100, Davide Viti a écrit : severity 457647 wishlist thanks those configuration file were added recently to the dejavu repository and ATM have to be considered as use at your own risk. I have no problem adding them to the debian package only after discussing their inclusion on the ML (Pkg-fonts-devel, DejaVu-fonts both cc'ed) as to know what other people think about it. FYI these files are just a dump of the configuration I use in Fedora, and should be pretty close to what Fedora 8 ships (I have tweaked them for fontconfig 2.5 before importing in DejaVu CVS, and this version is only shipped in Fedora devel right now) Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Bug#431983: [DejaVu-fonts] ttf-dejavu: extra space at the top of the lines in OpenOffice.org
Le mercredi 08 août 2007 à 19:57 +0200, Davide Viti a écrit : I've done a very simple test: tried to strip the entire 1D300:1D356 range off the ttf file and it fixed the problem; tried then with a ttf file containing only 1D300 and the problem reproduces. Please open an OO.o bug and forward the bug number there -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
