El dv 11 de 12 de 2009 a les 00:16 -0500, en/na Albert Cahalan va
> On Thu, Dec 10, 2009 at 4:47 PM, Pere Pujal i Carabantes
> <pere@...> wrote:
> > El dt 08 de 12 de 2009 a les 09:17 -0800, en/na Bill Kendrick va
> > escriure:
> >> On Tue, Dec 08, 2009 at 05:55:54AM -0500, Albert Cahalan wrote:
> >>> Consider the OLPC XO using Sugar's Journal. Ideally the
> >>> tuxpaint images would be available like anything else.
> >>> There are only two ways to make that work. Either we
> >>> embed everything in the PNG, or we abstract the extra data
> >>> to allow alternate storage mechanisms like Journal metadata.
> >> If you load a PNG-full-of-Tux-Paint-junk into another program
> >> (The GIMP, MS Paint, Krita, etc.) and edit it and save it back out,
> >> is it typical for apps to keep that metadata around? Or does it
> >> vanish the moment the program ignores it during the File->Open process? :)
> > Who cares? We can provide a plugin for The GIMP, to import/export tuxpaint png
> > files and convert our stuff to/from gimp entities. We can convert the labels to
> > gimp´s text layers or export text layers to tuxpaint labels, even we can embed
> > the starter and convert it accordingly, but really, why should we care if other
> > apps don´t know about the Tuxpaint file format? Currently they know nothing
> > about our .dat files nor our starters.
I mean that if any other app has _edited_ the png file, then this file
is no more a Tuxpaint png and we should consider it like any other image
that we can import.
> I care because the older kids want a way out of the captive
> file environment. Some may want normal file access, but my
> immediate concern is Sugar's Journal.
> In the Sugar environment, programs are not supposed to have
> access to the filesystem and are not supposed to have their
> own storage. The user selects a file first, then this is passed
> to the app ("Tux Paint activity") at start-up. If we want to open
> a second file, we ask the Sugar services to give the user an
> opportunity to select one. I think the user can even do this at
> random times, with Tux Paint getting a "here is a file for you!"
> message on D-BUS.
> Kids want to paint on their photos. Kids want to email their
> photos, embed them in those awful school reports, and so on.
> Special conversion software, gimp or otherwise, is not OK.
If I understand right, your main concern is having a single file with
all in it.
> > The only issue I see in embedding all the stuff in one file is the size of that
> > file, it will be more than the double of the main png, x3 if we embed
> > too the starter.
> If we start with a white background and don't add any labels
> or other fancy stuff, there must be NOTHING extra. This holds
> true no matter how the data is stored.
> I think we're way off right now. I saw some stuff in the .labels
> directory (which BTW should not be a dotfile) which looked
> like uninitialized data in PNG files.
Yep, I've still not looked in detail at the saving process, basically is
the same as left by GSOC. The more I think on it, the more I am
convinced that it should be changed, but I fail at find a good
I am considering from simply store the main png applying the label data
as plain text then discard the label data between sessions, up to store
all the data(image + labels) in a image format that allows multiple
layers, like xcf. Any of the options has its pros and cons.