Hi,
All of fonts is supposed to have an information page for their fonts at wiki based on the template[1] according to the package lifecycle[2]. however some of them doesn't have. so just tried to pick them up and inform you to get one there.
Please see the following source package list which may contains a font package that doesn't have an information page at wiki, and would be nice to have one for them.
[1]... https://fedoraproject.org/wiki/Font_description_template [2]... https://fedoraproject.org/wiki/Font_package_lifecycle
aalam saab-fonts ankursinha hiran-perizia-fonts ankursinha oldstandard-sfd-fonts asn powerline awjb libdockapp awjb wine bogado cave9 bojan grimmer-proggy-squaresz-fonts bojan grimmer-proggy-tinysz-fonts bsjones mscore bsjones rosegarden4 caolanm libreoffice chandankumar python-XStatic-roboto-fontface decathorpe impallari-raleway-fonts dkaspar urw-base35-fonts dvratil oxygen-fonts elad alef-fonts ellert root fale abattis-cantarell-fonts fangq wqy-bitmap-fonts fangq wqy-unibit-fonts fangq wqy-zenhei-fonts frixxon drehatlas-warender-bibliothek-fonts frixxon drehatlas-widelands-fonts frixxon drehatlas-xaporho-fonts fujiwara bicon hadess eosrei-emojione-fonts immanetize glyphicons-halflings-fonts jnovy TeXmacs jpena python-XStatic-bootswatch jpena python-XStatic-mdi jujens astloch-fonts jujens carterone-fonts jujens cyreal-wireone-fonts jujens kranky-fonts jujens labelleaurore-fonts jujens monofett-fonts jujens reeniebeanie-fonts jujens shadowsintolight-fonts jujens unifrakturmaguntia-fonts jujens vt323-fonts jujens wallpoet-fonts jwrdegoede zvbi kvolny horai-ume-fonts leamas entypo-fonts leamas mnmlicons-fonts limb extremetuxracer limb gnu-free-fonts limb lilypond lmacken nethack luya aajohan-comfortaa-fonts luya blender luya julietaula-montserrat-fonts luya julietaula-montserrat-fonts luya typetype-molot-fonts lyosnorezel thibault-fonts martinkg vdrsymbol-fonts marwin labiryntowy-fonts melmorabity lato-fonts mohammedisam layla-fonts mycae mathgl ndim terminus-fonts ngompa d-din-fonts nim bitstream-vera-fonts oget serafettin-cartoon-fonts ozamosi msimonson-anonymouspro-fonts petersen sil-gentium-fonts pnemade aldusleaf-crimson-text-fonts pnemade almas-mongolian-title-fonts pnemade ekmukta-fonts pnemade google-roboto-mono-fonts pnemade google-roboto-slab-fonts pnemade impallari-lobster-fonts pnemade iso8859-2-fonts pnemade kurdit-unikurd-web-fonts pnemade moyogo-molengo-fonts pnemade oflb-asana-math-fonts pnemade pagul-fonts pnemade sarai-fonts pnemade tabish-eeyek-fonts pnemade tharlon-fonts pnemade tuladha-jejeg-fonts ppisar sil-mingzat-fonts pravins bitmap-fonts pravins cdac-sakal-marathi-fonts pravins google-noto-fonts pravins gubbi-fonts pravins kalapi-fonts pravins nafees-naskh-fonts pravins nafees-nastaleeq-fonts pravins nafees-pakistani-naskh-fonts pravins nafees-pakistani-web-naskh-fonts pravins nafees-riqa-fonts pravins nafees-tehreer-naskh-fonts pravins nafees-web-naskh-fonts pravins navilu-fonts pravins paktype-ajrak-fonts pravins paktype-naqsh-fonts pravins paktype-naskh-basic-fonts pravins smc-fonts pravins ucs-miscfixed-fonts pvoborni fontawesome-fonts pwu adobe-source-han-sans-cn-fonts pwu adobe-source-han-sans-tw-fonts pwu adobe-source-han-serif-cn-fonts pwu adobe-source-han-serif-tw-fonts pwu baekmuk-bdf-fonts pwu baekmuk-ttf-fonts pwu cjkuni-ukai-fonts pwu cjkuni-uming-fonts pwu google-noto-cjk-fonts pwu google-noto-emoji-fonts pwu manchu-fonts pwu nhn-nanum-gothic-coding-fonts pwu nhn-nanum-gothic-light-fonts pwu sil-nuosu-fonts pwu ukij-tuz-fonts pwu un-core-fonts pwu un-extra-fonts pwu wqy-microhei-fonts rajeeshknambiar paratype-pt-mono-fonts rajeeshknambiar paratype-pt-serif-fonts raphgro apx raphgro cmatrix rathann fontsquirrel-crete-round-fonts rdieter jsmath-fonts rdieter lyx remi php-tcpdf rrankin denemo ryansb pcaro-hermit-fonts sagitter pioneer sarantis ctan-cm-lgc-fonts sarantis ctan-kerkis-fonts spot librecad suraia adobe-source-serif-pro-fonts susmit kanotf-fonts susmit levien-museum-fonts tagoh japanese-bitmap-fonts tagoh jisksp16-1990-fonts tagoh knm-new-fixed-fonts tomspur python-matplotlib vtrefny freecol zbyszek gust-antykwa-torunska-fonts zbyszek mathjax zbyszek unifont zdohnal ghostscript-fonts
On Tuesday, 21 November 2017 at 11:14, Akira TAGOH wrote:
Hi,
All of fonts is supposed to have an information page for their fonts at wiki based on the template[1] according to the package lifecycle[2]. however some of them doesn't have. so just tried to pick them up and inform you to get one there.
Please see the following source package list which may contains a font package that doesn't have an information page at wiki, and would be nice to have one for them.
[1]... https://fedoraproject.org/wiki/Font_description_template [2]... https://fedoraproject.org/wiki/Font_package_lifecycle
[...]
rathann fontsquirrel-crete-round-fonts
https://fedoraproject.org/wiki/Crete_Round_fonts updated, thanks for the reminder.
Regards, Dominik
On 11/21/2017 11:14 AM, Akira TAGOH wrote:
zdohnal ghostscript-fonts
ghostscript-fonts is deprecated by urw-fonts and urw-base35-fonts in Fedora 27+ and is going to be retired for them, so I won't create wiki page for it.
On Tue, Nov 21, 2017 at 03:44:05PM +0530, Akira TAGOH wrote:
All of fonts is supposed to have an information page for their fonts at wiki based on the template[1] according to the package lifecycle[2]. however some of them doesn't have. so just tried to pick them up and inform you to get one there.
Are they? From the lifecycle page you link, that seems to be there to enable the packaging of the font in the first place, not meant to be long-term documentation. If it _is_ meant to be long-term documentation, that should be clarified somewhere. Who is the audience for this documentation?
If it's supposed to be for end users (and that's a great goal!), I think the new docs site would be better than the wiki.
If it's for contributors and packagers, wouldn't it be better to have the documentation in a README.md in dist-git, next to the spec file? That way, it'd show up at (for example) https://src.fedoraproject.org/rpms/overpass-fonts
On Thu, Nov 23, 2017 at 3:31 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Nov 21, 2017 at 03:44:05PM +0530, Akira TAGOH wrote:
All of fonts is supposed to have an information page for their fonts at wiki based on the template[1] according to the package lifecycle[2]. however some of them doesn't have. so just tried to pick them up and inform you to get one there.
Are they? From the lifecycle page you link, that seems to be there to enable the packaging of the font in the first place, not meant to be long-term documentation. If it _is_ meant to be long-term documentation, that should be clarified somewhere. Who is the audience for this documentation?
That could be. as some of the wiki pages contains the sample rendering, that should definitely be helpful for the end users too to see how it looks like. unfortunately not available everything. we could improve it. For the audience, I don't know.. maybe Nicolas Mailhot?
If it's supposed to be for end users (and that's a great goal!), I think the new docs site would be better than the wiki.
Sure. yes, I like it. that depends what sort of information we provide though, the wiki pages can be easily outdated if noone maintains. so maybe nice to have the sort of web apps or any infrastructure working at the background to generate information from the packages and so on. well, we could do that with wiki even though.
If it's for contributors and packagers, wouldn't it be better to have the documentation in a README.md in dist-git, next to the spec file? That way, it'd show up at (for example) https://src.fedoraproject.org/rpms/overpass-fonts
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Nov 23, 2017, at 11:46 AM, Akira TAGOH wrote:
On Thu, Nov 23, 2017 at 3:31 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Nov 21, 2017 at 03:44:05PM +0530, Akira TAGOH wrote:
All of fonts is supposed to have an information page for their fonts> >> at wiki based on the template[1] according to the package lifecycle[2]. however some of them doesn't have. so just tried to pick> >> them up and inform you to get one there.
Are they? From the lifecycle page you link, that seems to be there to> > enable the packaging of the font in the first place, not meant to be> > long-term documentation. If it _is_ meant to be long-term documentation, that should be clarified somewhere. Who is the audience> > for this documentation?
That could be. as some of the wiki pages contains the sample rendering, that should definitely be helpful for the end users too to> see how it looks like. unfortunately not available everything. we could improve it. For the audience, I don't know.. maybe Nicolas Mailhot?
If it's supposed to be for end users (and that's a great goal!), I think the new docs site would be better than the wiki.
Sure. yes, I like it. that depends what sort of information we provide> though, the wiki pages can be easily outdated if noone maintains. so maybe nice to have the sort of web apps or any infrastructure working> at the background to generate information from the packages and so on.> well, we could do that with wiki even though.
i suspect we could do the same for the docs site. We could create a font catalog with sample rendered to images (I hope someone knows how to do this in an automated way). We could probably also gate showing a font based on some kind of a test (dnf to see if the package exists? Did the render succeed?). Lastly, we could theoretically trigger a republish based on both new pages added and fedmsgs about package updates. Regards,
bex
If it's for contributors and packagers, wouldn't it be better to have> > the documentation in a README.md in dist-git, next to the spec file?> > That way, it'd show up at (for example) https://src.fedoraproject.org/rpms/overpass-fonts
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org>
-- Akira TAGOH _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Nov 23, 2017 at 04:16:27PM +0530, Akira TAGOH wrote:
On Thu, Nov 23, 2017 at 3:31 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Nov 21, 2017 at 03:44:05PM +0530, Akira TAGOH wrote:
All of fonts is supposed to have an information page for their fonts at wiki based on the template[1] according to the package lifecycle[2]. however some of them doesn't have. so just tried to pick them up and inform you to get one there.
Are they? From the lifecycle page you link, that seems to be there to enable the packaging of the font in the first place, not meant to be long-term documentation. If it _is_ meant to be long-term documentation, that should be clarified somewhere. Who is the audience for this documentation?
That could be. as some of the wiki pages contains the sample rendering, that should definitely be helpful for the end users too to see how it looks like. unfortunately not available everything. we could improve it. For the audience, I don't know.. maybe Nicolas Mailhot?
I think we should consider getting rid of this requirement. Updating wiki pages is quite a bit of work, and we have better mechanisms to advertise stuff to users that didn't exist a few years ago. Apart from the manual effort, the problem with wiki pages is that they tend to get out of date pretty quickly enough to be out-of-date to often to be really trustworthy. Instead, I think it'd be better to spend the effort on making gnome software support fonts even better and to improve the appdata files for fonts to make them "shine" in gnome-software. This would be
a) less effort (a few minutes to create an appdata file when initially packaging the font, very little ongoing effort, metadata is automatically updated on package updates),
b) actually more useful for users (you get a live list, click "install" on the font you like, instead of going from a wiki page to the command line).
I attached a screenshot from gnome-software-3.26.1-3.fc27.x86_64 for a random font. This _is_ already pretty good, but it'd be nice to get rid of the "No screenshot provided" thing. Why would gnome-software show that? It could only useful for developers, but fonts actually don't need a screenshot, and the space could be used to show more text...
Also, most fonts don't have good descriptions in the appdata files. _This_ is something that requires font maintainer input.
/cc Richard Hughes
Zbyszek
PS. The screenshots also at https://in.waw.pl/~zbyszek/fedora/gnome-software-font.png, https://in.waw.pl/~zbyszek/fedora/gnome-software-font2.png, in case the attachments don't get through.
If it's supposed to be for end users (and that's a great goal!), I think the new docs site would be better than the wiki.
Sure. yes, I like it. that depends what sort of information we provide though, the wiki pages can be easily outdated if noone maintains. so maybe nice to have the sort of web apps or any infrastructure working at the background to generate information from the packages and so on. well, we could do that with wiki even though.
If it's for contributors and packagers, wouldn't it be better to have the documentation in a README.md in dist-git, next to the spec file? That way, it'd show up at (for example) https://src.fedoraproject.org/rpms/overpass-fonts
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Akira TAGOH _______________________________________________ fonts mailing list -- fonts@lists.fedoraproject.org To unsubscribe send an email to fonts-leave@lists.fedoraproject.org
On 23 November 2017 at 13:55, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote: [...]
I think we should consider getting rid of this requirement. Updating wiki pages is quite a bit of work, and we have better mechanisms to advertise stuff to users that didn't exist a few years ago. Apart from the manual effort, the problem with wiki pages is that they tend to get out of date pretty quickly enough to be out-of-date to often to be really trustworthy. Instead, I think it'd be better to spend the effort on making gnome software support fonts even better and to improve the appdata files for fonts to make them "shine" in gnome-software. This would be
a) less effort (a few minutes to create an appdata file when initially packaging the font, very little ongoing effort, metadata is automatically updated on package updates),
b) actually more useful for users (you get a live list, click "install" on the font you like, instead of going from a wiki page to the command line).
There are still some dinosaurs who don't use GNOME.
Maybe some mechanisms that aren't dependent on that would be good?
On 23 November 2017 at 20:34, Will Crawford billcrawford1970@gmail.com wrote:
There are still some dinosaurs who don't use GNOME.
AppStream is a cross distro and cross desktop specification. It's used by Muon, Discover and Apper on KDE, AppCenter on Elementary OS and also desktop neutral projects like Cockpit.
Richard
On Thu, Nov 23, 2017 at 08:34:35PM +0000, Will Crawford wrote:
On 23 November 2017 at 13:55, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote: [...]
I think we should consider getting rid of this requirement. Updating wiki pages is quite a bit of work, and we have better mechanisms to advertise stuff to users that didn't exist a few years ago. Apart from the manual effort, the problem with wiki pages is that they tend to get out of date pretty quickly enough to be out-of-date to often to be really trustworthy. Instead, I think it'd be better to spend the effort on making gnome software support fonts even better and to improve the appdata files for fonts to make them "shine" in gnome-software. This would be
a) less effort (a few minutes to create an appdata file when initially packaging the font, very little ongoing effort, metadata is automatically updated on package updates),
b) actually more useful for users (you get a live list, click "install" on the font you like, instead of going from a wiki page to the command line).
There are still some dinosaurs who don't use GNOME.
Maybe some mechanisms that aren't dependent on that would be good?
I'd try to write a page generator that'd turn appdata files into html. Might be useful for more than fonts. That doesn't even seem like that much work, to write such a script and have it run once a week and update the html for all updated packages and push it out to a server somewhere.
Zbyszek
On Thu, Nov 23, 2017 at 4:33 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Nov 23, 2017 at 08:34:35PM +0000, Will Crawford wrote:
On 23 November 2017 at 13:55, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote: [...]
I think we should consider getting rid of this requirement. Updating wiki pages is quite a bit of work, and we have better mechanisms to advertise stuff to users that didn't exist a few years ago. Apart from the manual effort, the problem with wiki pages is that they tend to get out of date pretty quickly enough to be out-of-date to often to be really trustworthy. Instead, I think it'd be better to spend the effort on making gnome software support fonts even better and to improve the appdata files for fonts to make them "shine" in gnome-software. This would be
a) less effort (a few minutes to create an appdata file when initially packaging the font, very little ongoing effort, metadata is automatically updated on package updates),
b) actually more useful for users (you get a live list, click "install" on the font you like, instead of going from a wiki page to the command line).
There are still some dinosaurs who don't use GNOME.
Maybe some mechanisms that aren't dependent on that would be good?
I'd try to write a page generator that'd turn appdata files into html. Might be useful for more than fonts. That doesn't even seem like that much work, to write such a script and have it run once a week and update the html for all updated packages and push it out to a server somewhere.
It'd be nice to integrate this into our package/software search system[1]. That way the information returned is richer and more useful...
Also, I wonder why packages.fedoraproject.org doesn't already point to this...?
[1]: https://apps.fedoraproject.org/packages/
On Thu, Nov 23, 2017 at 11:05:10PM -0500, Neal Gompa wrote:
On Thu, Nov 23, 2017 at 4:33 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Nov 23, 2017 at 08:34:35PM +0000, Will Crawford wrote:
On 23 November 2017 at 13:55, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote: [...]
I think we should consider getting rid of this requirement. Updating wiki pages is quite a bit of work, and we have better mechanisms to advertise stuff to users that didn't exist a few years ago. Apart from the manual effort, the problem with wiki pages is that they tend to get out of date pretty quickly enough to be out-of-date to often to be really trustworthy. Instead, I think it'd be better to spend the effort on making gnome software support fonts even better and to improve the appdata files for fonts to make them "shine" in gnome-software. This would be
a) less effort (a few minutes to create an appdata file when initially packaging the font, very little ongoing effort, metadata is automatically updated on package updates),
b) actually more useful for users (you get a live list, click "install" on the font you like, instead of going from a wiki page to the command line).
There are still some dinosaurs who don't use GNOME.
Maybe some mechanisms that aren't dependent on that would be good?
I'd try to write a page generator that'd turn appdata files into html. Might be useful for more than fonts. That doesn't even seem like that much work, to write such a script and have it run once a week and update the html for all updated packages and push it out to a server somewhere.
It'd be nice to integrate this into our package/software search system[1]. That way the information returned is richer and more useful...
Also, I wonder why packages.fedoraproject.org doesn't already point to this...?
Yeah, that'd be absolutely great.
It seems that this would require two steps: first a service which exports the appdata information on the web somewhere in standarized format, and then code in fedora-packages to display that information. (The reason why fedora-packages cannot do this directly is that appdata information can only be reliably extracted from the final rpm, and that's a slow operation). I cc'd recent fedora-packages contributors, maybe they can provide more info.
Zbyszek
Hi,
fedora-packages is already using the appdata to get the icons of the applications. The indexing of the search database is fetching an xml file [1] that contains the appdata but I am not sure how this file is actually produced.
[1] : http://dl.fedoraproject.org/pub/alt/screenshots/f27/fedora-27.xml.gz
Clement
I'd try to write a page generator that'd turn appdata files into html. Might be useful for more than fonts. That doesn't even seem like that much work, to write such a script and have it run once a week and update the html for all updated packages and push it out to a server somewhere.
It'd be nice to integrate this into our package/software search system[1]. That way the information returned is richer and more useful...
About 3 years ago, adding appstream data to fonts was done: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... Does it not help showing the details in various software centres?
On Thu, Nov 23, 2017 at 7:25 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I think we should consider getting rid of this requirement. Updating wiki pages is quite a bit of work, and we have better mechanisms to advertise stuff to users that didn't exist a few years ago. Apart from the manual effort, the problem with wiki pages is that they tend to get out of date pretty quickly enough to be out-of-date to often to be really trustworthy. Instead, I think it'd be better to spend the effort on making gnome software support fonts even better and to improve the appdata files for fonts to make them "shine" in gnome-software. This would be
I have no objections if we can have much better way. I like less manual effort.
-
Akira TAGOH -
Brian Exelbierd -
Clement Verna -
Dominik 'Rathann' Mierzejewski -
Matthew Miller -
Neal Gompa -
Rajeesh K V -
Richard Hughes -
Will Crawford -
Zbigniew Jędrzejewski-Szmek -
Zdenek Dohnal