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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]