[oe] Bug 2430 -- TrueType fonts handling and solution for it

[Paul Sokolovsky]

Hello Marcin,

Monday, January 21, 2008, 3:08:31 PM, you wrote:

> http://bugs.openembedded.net/show_bug.cgi?id=2430

> Rolf Leggewie tries to solve problem when TrueType/OpenType fonts are used
> in OPIE or other environments.

> Currently installing new font does not add it into list of available ones
> as there is no consensus how to handle it. I want to tell how I see it.

> 1. There will be /etc/update-fonts.d/ directory where
>    packages/environments will add own scripts for handling fonts
> 2. There will be "update-fonts" package which contain script which calls
>    all those scipts (via "run-parts /etc/update-fonts.d/" command)
> 3. "opie-ttf-support" script will install "update-qtttffontdir" command in
>    ${bindir} and script which will call it in /etc/update-fonts.d/
> 4. "fontconfig-utils" will also store own script in /etc/update-fonts.d/
> 5. packages/ttf-fonts/ttf.inc will RDEPEND on "update-fonts" and will call
>    it in postinst/postrm
> 6. qpf.bbclass (which should be renamed to qpf.inc and moved to
>    packages/qpf-fonts) will also RDEPEND on "update-fonts" and will call
>    it in postinst/postrm
> 7. qpf fonts will also RDEPEND on qte-fonts-common which
>    provide "update-qtfontdir" script

> This way we have solution which can be extended to any format of fonts and
> into any environment without changing anything. If someone will 
> create "XDE" which do not use fontconfig but use TrueType fonts then it
> will only need to install own script into /etc/update-fonts.d/ to have
> them supported.

> Any ideas/objections?

  Is such extra level of indirection and multiplexing really required?
Or rather, I wish we separated this matter to 2 separate ones:

1. Adopting reusable pattern for solving task of "need to 'register'
objects of arbitrary type".
2. See what kind of registration support required for objects of type
fonts.


For 1, I wish we adopted some easy scheme, like, for all packages
containing object of type foo, to have in postinstall:

[ -x /usr/bin/update-foo ] && /usr/bin/update-foo


Then, for each specific object type, specific package will handle
registration, for example among following (but not limiting to)
choices:

1. No registration needed at all - no /usr/bin/update-foo, nothing
will be done.
2. In simplest case, /usr/bin/update-foo will be a symlink to tool
handling registration for specific environment.
3. If some objects really need registration with different facilities,
multiplex scheme as described can be used.


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com