Bug 1532523 - [google-droid-fonts] rebase to latest version
Summary: [google-droid-fonts] rebase to latest version
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: google-droid-fonts
Version: rawhide
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Nicolas Mailhot
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-09 09:01 UTC by David Kaspar [Dee'Kej]
Modified: 2019-04-09 07:36 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description David Kaspar [Dee'Kej] 2018-01-09 09:01:58 UTC
Description of problem:
Currently we are using outdated font versions (of google-droid-fonts) in Fedora.

Version-Release number of selected component (if applicable):
google-droid-fonts-20120715-12.fc27

Expected results:
I would hereby like to request a rebase to latest version of google-droid-fonts.

Additional info:
One of these fonts (DroidSansFallback.ttf) in the package is necessary for Ghostscript to function correctly when rendering CJK glyphs.

And according to the Fedora Packaging Guidelines packages are forbidden to bundle fonts inside them, therefore I am using the google-droid-fonts package. But it's content is way older than what Ghostscript currently needs.

NOTE:
In case none of the maintainers is currently available, I'm able and willing to do this rebase myself (I'm already maintainer of urw-base35-fonts) to help you. You would just have to set commit right for me in the Pagure (https://src.fedoraproject.org/rpms/google-droid-fonts).

Comment 1 David Kaspar [Dee'Kej] 2018-02-01 13:26:09 UTC
Any update on this, guys?

Comment 2 Nicolas Mailhot 2018-02-01 14:58:29 UTC
Hi,

Please don't wait on me to do the upgrade, I'm lost in a deep and dark pit of Fedora Go packaging right now, and I don't think I'll emerge soon.

The Droid spec file should be fine as is but updating Droid usually requires combing through many gigabytes of AOSP git trees. That takes time and bandwidth. There is no formal process for releasing Droid Google-side, what's in Fedora (or Google font library) is usually an obsolete version someone managed to scrap from Android sources.

Comment 3 Fedora End Of Life 2018-02-20 15:27:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 4 David Kaspar [Dee'Kej] 2018-02-28 16:57:54 UTC
(In reply to Nicolas Mailhot from comment #2)
> Hi,
> 
> Please don't wait on me to do the upgrade, I'm lost in a deep and dark pit
> of Fedora Go packaging right now, and I don't think I'll emerge soon.
> 
> The Droid spec file should be fine as is but updating Droid usually requires
> combing through many gigabytes of AOSP git trees. That takes time and
> bandwidth. There is no formal process for releasing Droid Google-side,
> what's in Fedora (or Google font library) is usually an obsolete version
> someone managed to scrap from Android sources.

I would just update the Google's Droid Sans Fallback, Droid Sans Fallback Full, and Droid Sans Mono, which are still present in repository. The rest doesn't seem to receive an update before.

However, for that I need a commit rights for the repository in Fedora, to be able to submit new sources. (I'm not proven packager.)

Best regards,

 -- Dee'Kej --

Comment 5 David Kaspar [Dee'Kej] 2018-04-17 14:58:39 UTC
Any news guys? :)

Comment 6 Jens Petersen 2018-04-26 04:23:26 UTC
I just had a look in Android Git:

https://android.googlesource.com/platform/frameworks/base.git/+/kitkat-release/data/fonts/ seems the last release with a broad set of Droid fonts?

Currently very few fonts: https://android.googlesource.com/platform/frameworks/base.git/+/oreo-release/data/fonts/

Dunno if they were moved somewhere else or replaced?

Comment 7 Jens Petersen 2018-04-26 04:24:36 UTC
Perhaps we could just updated the Fallback font and keep the rest as is?

Comment 8 Jens Petersen 2018-04-26 04:27:15 UTC
Or update to the KitKat fonts plus latest Oreo/master.

Comment 9 Nicolas Mailhot 2018-04-26 09:57:28 UTC
@Jens: we should pick the latest version of each component of Droid from all the various android trees. Google has always been terrible at publishing this font, they probably have a master version somewhere internal, we only see the bits they deem suitable and they vary from Android release to release depending on the other fonts in each release and the markets they wish to target (it may even be that some droid bits are only in specific vendor branches).

The font is very nice but locating its parts is a lot of work.

Comment 10 Nicolas Mailhot 2018-04-26 10:08:28 UTC
PS Droid Fallback is a high coverage – low quality compromise. As a rule the same glyphs in locale-specific Droid parts will always be higher quality.

That’s why the package tries to ship as many locale-specific bits as possible and Droid has a complex fontconfig file that mashes everything in a single droid family making sure fallback is only used when there is no better Droid part available.

Well, the fontconfig file is not complex as in hard, it’s complex as a bit involved and requiring enough packager involvement to understand the fontconfig logic instead of cargo-culting default config file templates with no understanding. 

Noto should probably benefit from the same setup, as it has the same characteristics (wide encoding font spread over many files that need merging in a single Noto font family by fontconfig instead of forcing users to assemple them manually)

Comment 11 David Kaspar [Dee'Kej] 2018-04-26 10:22:23 UTC
(In reply to Nicolas Mailhot from comment #9)
> @Jens: we should pick the latest version of each component of Droid from all
> the various android trees. Google has always been terrible at publishing
> this font, they probably have a master version somewhere internal, we only
> see the bits they deem suitable and they vary from Android release to
> release depending on the other fonts in each release and the markets they
> wish to target (it may even be that some droid bits are only in specific
> vendor branches).
> 
> The font is very nice but locating its parts is a lot of work.

From what I've seen/deduced from looking at the git repository logs, the Google Droid is no longer used as primary fonts for CJK-based glyphs. From what I've been told, people hated those fonts.

Google is switching to different fonts in Android because of it. IIRC they are using Noto fonts for it as a replacement. IMHO it might make sense to start dropping support of Google Droid Fonts in favor of Google Noto, since Google Noto is still receiving updates...

For what I need from the fonts right now is just update of Google Droid Fallback font. It seems outdated (in regards of timestamps & sizes) compared to version that Ghostscript needs/is using.

If we can't get the update for the Droid Fallback, then I would have to bundle the same font in Ghostscript package (so it functions as we need), which would be also against Fedora Packaging Guidelines (I would like to avoid that).

NOTE: Ghostscript is using the Google Droid Fallback for displaying of CJK glyphs in case the CJK-based documents do not contain embedded fonts for the glyphs (or the necessary fonts are not installed on the system).

Comment 12 Nicolas Mailhot 2019-04-09 07:36:57 UTC
And I did all the grunt work two months ago

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/build/858473/

(with a lot of similar work for many many Fedora i18n font packages)

However, it can not be pushed to devel before redhat-rpm-config maintainers finish processing the last macro bits of
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51

(4 months old PR)

This is seriously depressing, I have other things to do than beg them continuously to look at the PR or state the changes they want in the macro code. If that continue I will probably just mass orphan all the font packages I'm supposed to look after.


Note You need to log in before you can comment on or make changes to this bug.