Any update on this, guys?

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.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

(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 --

Any news guys? :)

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?

Perhaps we could just updated the Fallback font and keep the rest as is?

Or update to the KitKat fonts plus latest Oreo/master.

@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.

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)

(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).

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.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.