RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Proposed usabillity enhancement for PNG handling

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

7 of 9 messages available
Toggle history

Please log in to manage your subscriptions.
Proposed usabillity enhancement for PNG handling Alexia Death 12 Oct 20:26
  200810122145.52592.alexiade... Alexia Death 12 Oct 20:45
  Proposed usabillity enhancement for PNG handling Martin Nordholts 13 Oct 20:01
  Proposed usabillity enhancement for PNG handling Sven Neumann 13 Oct 20:07
   Proposed usabillity enhancement for PNG handling Alexia Death 13 Oct 20:28
    Proposed usabillity enhancement for PNG handling Michael Natterer 13 Oct 23:13
    Proposed usabillity enhancement for PNG handling peter sikking 13 Oct 23:45
mailman.3.1224097204.15712.... 07 Oct 20:26
  Proposed usabillity enhancement for PNG handling Alchemie foto\\grafiche 16 Oct 20:27
Alexia Death
2008-10-12 20:26:45 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

Hi!

PNG-s support offset for whatever renders them in the file format. However, the way GIMP handles the offset is less than optimal. I've included a sample image for anybody interested to see for themselves.

So whats the issue? The file is loaded with the layer offset on canvas. That is not productive if the person has opened the image to EDIT it. You need to correct the offset first, then edit. Then you need to somehow restore your offset and save remembering to check the "Save layer offset" check box. If you forgot and closed GIMP before noticing this you end up with a broken and ruined image and lost work. This is not good.

My suggestion is as follows: a) do not apply the th offset to the layer. b) save offsets from load time
c) add numeric entry boxes to the save dialog and fill them with load time offset values.

This lets the person open edit and save the particular kind of PNG-s without any extra hassle and loss of productivity.

-- Alexia

Martin Nordholts
2008-10-13 20:01:31 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

Alexia Death wrote:

My suggestion is as follows:
a) do not apply the th offset to the layer. b) save offsets from load time
c) add numeric entry boxes to the save dialog and fill them with load time offset values.

Hi

For the record, I think this suggestion makes sense

BR, Martin

Sven Neumann
2008-10-13 20:07:15 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

On Sun, 2008-10-12 at 21:26 +0300, Alexia Death wrote:

PNG-s support offset for whatever renders them in the file format.

What's the purpose of these offsets? I find it difficult to judge your proposal without knowing what the spec says about this.

Sven

Alexia Death
2008-10-13 20:28:49 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

On Mon, Oct 13, 2008 at 9:07 PM, Sven Neumann wrote:

On Sun, 2008-10-12 at 21:26 +0300, Alexia Death wrote:

PNG-s support offset for whatever renders them in the file format.

What's the purpose of these offsets? I find it difficult to judge your proposal without knowing what the spec says about this.

I looked up the PNG spec about this already when first trying to decide if it was a bug or a feature.

To the letter spec says: "The oFFs chunk gives the position on a printed page at which the image should be output when printed alone. It can also be used to define the image's location with respect to a larger screen or other application-specific coordinate system."

I see it mainly as a a directive to the rendering engine to place the image at a offset. Its useful in contexts where PNG-s are used for rendering an UI etc. and supporting it is good. But in current implementation it is a hindrance to editing without any added benefits even to the user that WANTS to use it(see described use case in the first ). Now looking at spec, specially the last sentence, as I understand it these fields could be used to define an offset in a coordiante system totaly different of PNG-s own, with makes the way gimp handles it now totally incorrect for those usecases. The image can be unedtable because the system using it has a larger coordinate system and it ends up 100% outside canvas.

--Alexia

Michael Natterer
2008-10-13 23:13:44 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

On Mon, 2008-10-13 at 21:28 +0300, Alexia Death wrote:

On Mon, Oct 13, 2008 at 9:07 PM, Sven Neumann wrote: On Sun, 2008-10-12 at 21:26 +0300, Alexia Death wrote:
> PNG-s support offset for whatever renders them in the file format.


What's the purpose of these offsets? I find it difficult to judge your
proposal without knowing what the spec says about this. I looked up the PNG spec about this already when first trying to decide if it was a bug or a feature.

To the letter spec says: "The oFFs chunk gives the position on a printed page at which the image should be output when printed alone. It can also be used to define the image's location with respect to a larger screen or other application-specific coordinate system."

As mentioned already on IRC, I'm sure we had exactly the same bug with another image file format, and IIRC the bug was resolved by simply ignoring
the offsets. I've searched bugzilla but didn't find anything.

It maybe was BMP (could could have been TIFF or something else). Does anyone remember that old bug?

ciao, --mitch

peter sikking
2008-10-13 23:45:09 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

Alexia wrote:

To the letter spec says:
"The oFFs chunk gives the position on a printed page at which the image should be output when printed alone. It can also be used to define the image's location with respect to a larger screen or other application-specific coordinate system."

I would be happy if we could support this 'silently': if one opens and edits a png with these offsets then we write them on save again. copy the (whole/part) image data in another/new file and there are no offsets.

starting to really support managing these offsets is not outside the GIMP vision (making UI graphics), but needs better understanding of the workflows where this is used.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Alchemie foto\\grafiche
2008-10-16 20:27:42 UTC (over 16 years ago)

Proposed usabillity enhancement for PNG handling

P.S about how i save png i never use the option "ignore"

Scopri il blog di Yahoo! Mail: Trucchi, novità e scrivi la tua opinione. http://www.ymailblogit.com/blog