Re: [Gimp-developer] assets in the high bith depth age

["Joao S. O. Bueno" <gwidion mpc com br>]

I agree with the file-format,
ad I don't think keeping the i18n's in file is a bad thing to do.

The idea of having a file as a "pill" containing all the translations,
and such seens much
more tasty than having to distribute separated i18n resources when
I publish, say, a color palette on my blog.

Distributors of third party files are welcome to accept downstream
contributions to the assets
they create, or license their works in a way to allow for the creation
of new versions,
containing more languages.

However, one option does not exclude the other - the use of the
localization could be made in a way
to use either built-in translations for colors/metadata or look for
them in an external location
if the former way defaults. (then one could have the best of both Worlds)



  js
 -><-


On 9 February 2014 18:45, Ofnuts <ofnuts laposte net> wrote:
> On 02/09/2014 07:55 PM, Alexandre Prokoudine wrote:
> > Hi,
> >
> > I'm curious if we have a plan for assets in v2.10 and onwards now that
> > 16/32 bit is possible. Color palettes and gradients are still based on
> > raw 8bit RGB values, and pattern files are 8bit as well.
> >
> > FilmGIMP/Cinepaint "fixed" that in the past by converting everything
> > to 16bit integer (afaik, integer), but I'm not sure if that's such a
> > good idea.
> >
> > Some things to consider, in no particular order:
> >
> > - IMO, ideally, stock color palettes should be using a linear
> > device-independent color space (some sort of LCh?);
> > - it should be possible to use palettes that rely on arbitrary color
> > models (RGB, LAB) to make paint vendors happy;
> > - we still need to solve the i18n issue that was raised recently
> > (non-translatable palettes/colors/etc. names).
> >
> > In my opinion, a sensible way to approach that would be using an
> > already available, but somewhat forgotten file format devised by
> > Olivier Berten during his work on SwatchBooker:
> >
> > http://selapa.net/swatchbooker/
> >
> > To reiterate my earlier email to create@, the benefits of this file format
> > are:
> >
> > - simple combination of XML + ZIP
> > - (nearly) any color model + optional mapping to an embedded ICC profile
> > - flat colors and gradients supported
> > - spot colors supported
> > - i18n-ized names of all metadata fields and color names
> >
> > There is no other file format that would provide the same set of
> > features for us, free or non-free:
> >
> > http://www.selapa.net/swatches/colors/fileformats.php
> >
> > So the questions are:
> >
> > - Is changing the assets file format something we need to do for 2.10
> > (or maybe at all)?
> > - Is the SwatchBooker's file format right for us?
> > - do we actually have resources to make the switch?
> >
> > Opinions?
>
> Yes, that seems necessary.
>
> But I don't like much how i18n is handled in the SwatchBooker format.  I
> don't think the file should contain the names in multiple languages. Most
> resources distributed outside of Gimp (DeviantArt, etc...) are by isolated
> authors, and I would not expect their resources to be tagged in more than
> two or three languages (English plus their native languages). I18N support
> is done by users, and that would mean making a local version of the file to
> display the file in the user's language. I would think a single name in the
> file, remapped using a locale-dependent translation file (one in /usr/share
> on in the user's profile) would let users rename resources more efficiently.
> This method could also be used to display localized names for other
> resources (brushes, patterns...).
>
> _______________________________________________
> gimp-developer-list mailing list
> List address:    gimp-developer-list gnome org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list