Re: [RFC] Stripping Latin range in fonts used by g-i installer?
On 09/01/2008, Otavio Salvador <firstname.lastname@example.org> wrote:
> "Eddy Petrișor" <email@example.com> writes:
> > (Frans, sorry for the direct reply;I am still using gmail's web interface).
> > On 09/01/2008, Frans Pop <firstname.lastname@example.org> wrote:
> >> On Wednesday 09 January 2008, Eddy Petrișor wrote:
> >> > Why not do an automatic strip of the font and only *keep* the
> >> > codepoints that are used, based on the existing translations? I know
> >> > this could be too drastic and we run into the risk of loosing glyphs
> >> > if we are not doing this properly, but with Davide's graphic
> >> > comparison scripts we could detect such situations.
> >> This would then have to be a strip at D-I build time instead of font udeb
> >> build time, otherwise you'd have serious synchronization problems.
> > That's what the mask trick was supposed to cover. And would allow the
> > stripping to be done when building the font.
> Using a mask for it means that, depending of translation / templates
> changes we'd need to update it and rebuild all used fonts udeb against
There were two types of masks: mask to make sure a range of unicode
points is included and another to make sure such a range is entirely
The mask-include makes sure that even if a glyph is not used in the
current translation, it is included (example: mask-include the entire
cyrillic range for dejavu since dejavu is used for cyrillic
langauges). So even if some X unicode point from the range is not
used, we don't miss it.
The mask-exclude is done to make sure we can exclude ranges such as
the latin unicode points from the language specific fonts so that the
glyphs used for latin unicode points are the one from the dejavu font.
What the computation based on existing text accomplishes is to make
sure special signs, marks and such are used from the dedicated font.
(E.g. Vietnamese's usage of the mdash, iirc).
> If we're going to take this idea, the place for it is on d-i building
> process, not font udeb. That way we avoid this hassle.
No, in the font udeb build. What is needed from d-i environment is the
computed list, and that can be updated (only additions would make
sense in most cases) manually from time to time, or better, create a
small package that contains these lists which are maintained in he
same manner freefont stripping ranges are maintained now
 this shouldn't be a hassle, since what maintainance would suppose
for a list would be running a script to compute the compilation and
commit the new list in svn; when is time, upload the package.
"Imagination is more important than knowledge" A.Einstein