Andrew Farris wrote:
Hans de Goede wrote:
Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede@xxxxxx) said:
So, maybe I'm insane, but if all you want is a sans bold, etc. font
- that
can't be more than about 20 lines of fontconfig code to look for a
match
for the 'sans' pattern and get a filename. That way:
- you don't have to hardcode any files
- you don't have to hardcode any requirements
Erm, yes and our mantra is upstream, and most of these apps are
portable (using SDL + SDL_ttf for example), how am I going to get
this upstream, last I checked there was no fontconfig under windows,
let alone on devices like the gp2x.
Really this is not a problem of the apps, people should stop
thinking about this as being a problem of the apps, there are just
too many apps doing this, this should be fixed centrally.
Let me try to understand:
You would rather:
- add 2000 more file entries to the metadata for everyone to download
on every
update
- manually track when files move and update all your packages
than:
- add and carry a ~20 line patch that absolves you from having to fix
your
packages when they change?
<sigh> (getting somwwhat tired of discussion.
Basicly: yes
Because:
-adding a Requires: /usr/share/fonts/foo/bar.ttf line to my package is
trivial
-font renames are rare
-even if font renames happen fixes is easy
-games were designed with a certain look and feel, depending on
getting that
exacy font, fontconfig is somewhat fuzzy with which font you'll get
I would like to point out again, that because games are designed for a
specific metric to fit within a surface in a pixel size the game
developer chose to fit within theme of the game scene... the package
should be carrying the font as game data.
The rest of the Fedora world should not care about that game carrying a
minor portion of data specifically chosen to work well with that game's
rendering engine within its own scenes. However, the rest of the Fedora
world downloading filelists due to some game packages not carrying a
small font as game data seems a bit excessive. The game essentially
requires a font file (which it converts to images on a surface) as game
data; what rationale is there for it not being game data just because it
happens to exist elsewhere on the system in the same format? The only
benefit of that choice is a smaller game data package and smaller
installed size for those users who happen to install that game (are they
concerned about space while installing games?).
I know my opinion is just my own, but this seems backwards to me. If
the game is not using system font rendering it should be carrying the
font as its own data, just like the sprites and backgrounds it also no
doubt has.
That said, Hans you don't have to respond I know you've already
responded ('live with it'). Still, it seems like a solution to
significantly reduce bandwidth used by not pulling filelists as often
exists and is simple.
Actually keeping the font files as private data sounds like a reasonable
approach, given how important this appearantly is to people.
I don't find it elegant to carry system font files as private data, because
fonts get bugfixes too, and some games might benefit from these.
But shipping fonts as private data is what most games currenty actually do, and
given that they use their own rendering (and usually their own text encoding
schemes like latin1) this isn't completely strange either.
So if there are no objections I am willing to "fix" the 2 packages currently
symlink fonts (as replacement for microsoft fonts used by upstream) to just
include private copies of the currently symlinked fonts instead.
Although not 100% ellegant this will solve the filedep issue at hand, without
much downsides.
---
Alternative:
Put the files under /usr/share/fonts in the default metadata instead of in the
filelist. I know this are 2000 files, but that only goes for the main repo
metadata which is downloaded only once. The updates metadata should contain
only files of packages in updates, and although some fonts might get updates,
the list of files under /usr/share/fonts in updates should never grow really large.
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
