Re: Bunch of new Fonts added to wishlist
by Nicolas Mailhot
Le Lun 26 novembre 2007 15:53, Dave Crossland a écrit :
> Hi,
>
> I haven't done any Fedora packaging before, but I would be happy to
> help with this effort.
Welcome to the team!
I've tried to write complete documentation on fedora-style packaging
there
http://fedoraproject.org/wiki/SIGs/Fonts/Packaging
please ping the list if something stops you from packaging OFLB fonts.
Regards,
--
Nicolas Mailhot
16 years, 5 months
Bunch of new Fonts added to wishlist
by Máirín Duffy
Hi folks,
I just added a bunch of fonts to the font sig wishlist [1]. These are
fonts that I thought were pretty high-quality from an artistic POV from
the list of fonts [2] that I put together a couple of months back. I
would love to see some of these in F9 for the Art Studio spin.
I updated the spreadsheet [3] there, coloring fonts that are already in
Fedora blue, ones that are proposed on the wishlist green, and those
with an unacceptable license in grey.
I may go through some of the links at the top of the wishlist page and
see if I can find more suitably-licensed fonts; If I do I will update
the list below.
Anyhow, here's the list that I just added:
mgopen canonica
mgopen cosmetica
mgopen modata
mgopen moderna
epigrafica
gillius adf
GFS Didot
GFS Bodoni
GFS Neohellenic
GFS Artemisia
GFS Theokritos
GFS Olga
GFS Didot Classic
GFS Porson
GFS Baskerville
GFS Bodoni Classic
GFS Gazis
GFS Solomos
GFS Porson
GFS Complutum
Delphine Regular
Steve Hand
Dustismo Sans
Dustismo Roman
Dark Garden
Tuffy
Tuffy MH3
Isabella
Essays 1743
Rockets
Stay Puft
Kerkis
To Be Continued
Letters Laughing
Rubbing Font
Banana Peels
~m
[1] https://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline/WishList
[2] http://duffy.fedorapeople.org/fonts
[3] http://duffy.fedorapeople.org/fonts/font-study.ods
16 years, 5 months
Bunch of new Fonts added to review list
by Nicolas Mailhot
Hi all,
Inspired by Máirín's activity I've packaged a few fonts which are now
stuck into review:
https://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline?action=show#r...
They will probably be the last fonts I'll package since I don't believe
being responsible for too many different packages is healthy (ok I'll
probably finish the Greek Font Society fonts)
Some notes:
– these are all OTF fonts, so they won't work in apps that can't handle
this format. Some offenders are well-known (OpenOffice.org in
particular, see
http://fedoraproject.org/wiki/SIGs/Fonts/QA#known-problems). Go
comment/vote in the various upstream issue trackers if you want this
fixed.
– I didn't package the TrueType variants of the Greek Font Society
fonts: most of the TrueType archives do not include a clear license like
the OTF ones, they're older so I've no idea if they include the whole
last version of the fonts, they declare the same font names and I don't
want to find out how applications will react to the same font in two
different format on-system. I may reconsider if someone convinces the
Greek Font Society to release the same nice archives they did for OTF
fonts, and if the fonts in those archives declare a different font name
(for example GFS Didot TT)
– I used the font files most recent timestamp as version since the fonts
all declared a 1.0 version but had obviously been modified several times
in their lives. Again if someone convinces the Greek Font Society to use
proper versioning I may change this in the future.
– most fonts have been declared on fontconfig priority 60, which mean
they may take precendence over other latin fonts if neither DejaVu, nor
Liberation are installed. Nevertheless I didn't just blindly cut and
pasted fontconfig rules, but tried to adapt them to each font.
– I do not intend to group the Greek Font Society fonts in any
particular way. If there is enough user demand I may create a GFS comps
group, but right now I plan to just ship separate fonts files.
Regards,
--
Nicolas Mailhot
16 years, 5 months
[Fwd: Summary of the 2007-11-20 Packaging Committee meeting]
by Nicolas Mailhot
Hi,
The fonts SIG packaging policy was approved by FPC today. Next week
FESCO is expected to ratify the document and make it an official binding
Fedora policy.
Regards,
-------- Message transféré --------
De: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Répondre à: Development discussions related to Fedora
Sujet: Summary of the 2007-11-20 Packaging Committee meeting
Date: 20 Nov 2007 14:02:25 -0600
Meeting minutes and full logs of the packaging committee meeting which
occurred on 2007-11-20 are online:
http://fedoraproject.org/wiki/Packaging/Minutes
http://fedoraproject.org/wiki/Packaging/Minutes20071120
Executive summary:
No new guidelines this week.
Issues pending FESCO ratification:
* Policy for font packages:
* http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy
* Accepted (with changes) (5-0)
* Voting for: spot rdieter abadger1999 scop tibbs
* Abstaining: racor
* Some notes:
* There are components of the proposal which go beyond packaging
policy and are not considered by FPC. This includes the
CompsPolicy document and sections of the draft relating to
grouping or comps. These should be discussed by FESCo.
* http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate
was approved as part of this proposal with the caveat that the
scriptlets be prevented from failing.
Misc business:
* Three volunteers expressed interest in joining the committee; spot
will poll the membership and we'll decide whether to expand the
committee or rotate through some members on-list.
* Next meeting will be December 4th at 17:00UTC.
- J<
--
Nicolas Mailhot
16 years, 5 months
Re: [Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
by Nicolas Mailhot
Le Mar 20 novembre 2007 13:11, Hans de Goede a écrit :
> Nicolas Mailhot wrote:
>> Whatever solution you choose forcing installation of core fonts
>> backend by the main font package is a no-go for modern fonts
>> (TTF/OTF,
>> maybe Type 1 too).
>
> What do you mean with the "core fonts backend"?
Fonts accessed through the original X core protocol. Official
X11/XFree86/Xorg name of what you are writing about.
(http://keithp.com/~keithp/talks/xtc2001/paper/)
>> You can split the core font scriptlet parts in a
>> subpackage, or ship pre-generated files, as long as you do not
>> impact
>> the vast majority of users who have no need for core fonts.
>>
>
> Yes, assuming that with the "core fonts backend" you mean mkfontdir &
> friends,
> then I agree, having a dependency on these is not a good plan, so I
> see 2 options:
> 1) Use pregenerated files (I just checked there contents and I see
> nothing
> different from how they looked in the XFree86 3.x days, so I do
> not believe
> these are xorg version / arch / dpi dependent). This is the
> prefered option.
This was changed to scriptlets in the time we still had people caring
about core fonts so I wouldn't assume there were no technical reason
for the change. But I actively don't care whether core fonts work or
not so if you believe this will work and are ready to shoulder the
resulting QA you're free to go this way.
> 2) The gtk-update-icon-cache way, so conditionally run mkfontdir and
> friends
> from scripts, if installed. And on installation of mkfontdir, run
> it for all
> dirs under /etc/X11/fontpath.d
>
> I believe 1 si greatly preferred
We chose 2 for fontconfig, but if you do the work you call the shots,
as long as you conform to
http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy
Regards,
--
Nicolas Mailhot
16 years, 5 months
Re: [Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
by Nicolas Mailhot
Le Mar 20 novembre 2007 11:25, Hans de Goede a écrit :
> Isn't the solution for this problem (missing fonts.dir / fonts.scale)
> as simple
> as adding a single guideline that font packages which add a symlink
> under
> /etc/X11/fontpath.d MUST ship a pre-generated fonts.dir and
> fonts.scale, and no
> try to generate these using scriptlets?
IIRC pre-shipping these files caused other problems, but I doubt there
is enough core fonts expertise left to identify them easily (I vaguely
remember mkfontdir output was dependant on local hardware resolution
or xorg version). The people who knew core fonts innards dropped it
like radioactive material as soon as fontconfig was available.
Whatever solution you choose forcing installation of core fonts
backend by the main font package is a no-go for modern fonts (TTF/OTF,
maybe Type 1 too). You can split the core font scriptlet parts in a
subpackage, or ship pre-generated files, as long as you do not impact
the vast majority of users who have no need for core fonts.
--
Nicolas Mailhot
16 years, 5 months
Re: [Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
by Nicolas Mailhot
Le Mar 20 novembre 2007 10:32, Hans de Goede a écrit :
>> Obsolete core-protocol fonts are out of my expertise/interest so I
>> leave that to others.
>>
>
> Too bad, as that is the real problem,
Core fonts are basically under-maintained with few people willing to
invest the time to make them sort-of work. If you have an interest in
them you can drive this work on the fonts SIG list because otherwise
you may wait a long time for someone else to do it.
Or you can decide like a lot of people it's not worth it and upstreams
that refuse to change can find themselves other packagers.
Regards,
--
Nicolas Mailhot
16 years, 5 months
Re: [Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
by Behdad Esfahbod
On Sat, 2007-11-17 at 08:36 +0100, Hans de Goede wrote:
> Behdad Esfahbod wrote:
[snip]
> > Fontconfig doesn't store cache files in the directory anymore. They go
> > in /var/cache/fontconfig. That's been the case for a while.
>
> Ah, then the packages also should no longer ghost fc-cache in the fonts dir.
No, they shouldn't.
> >> As for the other two not being created, well that is to be expected if the
> >> necessary packages are not added to any Requires.
> >>
> >> Why are these files generated on install anyways, I understand this used to be
> >> usefull back in the days when multiple packages would install files under one
> >> dir, but isn't it so that most font dirs now only contain fonts from one package?
> >
> > I don't understand. When are you suggesting they should be generated?
>
> At package buildtime, and then simply include them in the package
> instead of %ghost them and generate them with scriptlets.
Interesting. Never thought about it like that. However, there are a
few reason why that's not going to work:
- fc-cache (and similar tools I assume) don't handle DESTDIR. You
sure can force them to do it, but it needs considerable effort on the
packagers side.
- fontconfig cache format/version changes over time. Mostly in a
compatible way, but still making old caches useless. This happened with
the recent 2.5 for example.
- Kind of rewording of the previous item: We're trying to make font
packages not depend on fontconfig. Would be kinda weird to install a
fontconfig cache file without checking fontconfig version.
I don't think cache updates are hassle enough to try to fix them right
now.
Obsolete core-protocol fonts are out of my expertise/interest so I leave
that to others.
> Regards,
>
> Hans
Regards,
--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
16 years, 5 months
Re: Review queue/FESCo after the merge
by Nicolas Mailhot
Le dimanche 18 novembre 2007 à 09:45 -0500, Jesse Keating a écrit :
> On Sun, 18 Nov 2007 15:11:00 +0100
> Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
>
> > Results from my work:
> > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls....
> >
> > @FESCo: so what do do with this? Commit and don't build? The package
> > owners should see the commit diff and spot errors if I did any.
>
> I have no problem with that, so long as the Fonts SIG is happy with the
> change.
I stated when I started the SIG I didn't want the glorious leader
position, so I won't pretend I speak for it, and I'll only object for
the three affected packages I maintain or co-maintain.
If this change is to be done I'll insist his author explain and defend
it on the SIG list, then write a formal FPC proposal, and get this
proposal approved all the way up.
This is a "fix"¹ in search of a problem², and while I've been known to
make gratuitous changes to make a point too³, I've limited myself to my
own packages, and I'll appreciate the same restraint in my fellow
Fedorans.
I don't mind people touching my packages, but only if there are actual
problems to fix.
Regards,
¹ That can actually increase the probability bad packages make it
through QA
² One documented failure in rawhide does not count, if we shot
everything that ever went wrong in rawhide little would be left
³ Yes I'm a bastard too.
--
Nicolas Mailhot
16 years, 5 months