After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 164774 - The zero point position on both rulers should be movable.
The zero point position on both rulers should be movable.
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
2.2.x
Other All
: Low enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 600452 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-20 23:42 UTC by Rodd Clarkson
Modified: 2018-05-24 11:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rodd Clarkson 2005-01-20 23:42:36 UTC
I would like to be able to move the zero point on the rulers so as to set some
other position in the image as 0,0 than the top left corner of the image.

In my case I work a lot with web pages where the 0,0 position for designs are
actually somewhere inside the page, with div elements (position:absolute)
hanging out in the negative area.  Currently, I have to mark all the positions
based on 0,0 being in the top left corner and then recalculate where the
elements should actually be for laying out with CSS.  Being able to move the 0,0
point to the appropriate point in the document would save me quite a lot of work.

I'm sure there are plenty of other good reasons for this sort of functionality.
 Photoshop supports the ability to move the zero point in the rulers.

Also, on a related note, it might also be useful to be able to change the
direction of the rulers in terms of negative and positive.  This might be useful
for consistency with other applications (for example Freehand had 0,0 in the
bottom left corner of the screen, with postive numbers running up and across to
the right) or again to help with layout of elements (for example, one of the
perl PDF modules positions in a similar manner to Freehand).

I'm not sure how hard and of this is.  I imagine that moving the zero point on
the ruler should be relatively easy (possibly some handles and a 'recalculation'
of what numbers are displayed (what do I know ;-]) but suspect that the later
(changing the negative/positive direction of rulers would involve some
non-trivial changes to many dialogs involved in positioning elements.  Then
again, what would I know, I'm just the twit filing a feature request. ;-]
Comment 1 Rodd Clarkson 2005-01-20 23:44:16 UTC
Oh, I should say that all this might be possible, but I couldn't find anything
regarding it in either the GIMP help files, or using Google.  If this
functionality exists then this bug report should be about making this feature
known in the documentation.
Comment 2 weskaggs 2005-02-25 19:20:23 UTC
Might as well confirm, since it's a reasonable request, but I'm setting the
priority to "low".  If the masses start revolting, we can raise the priority.
Comment 3 Vitali 2005-09-19 11:55:48 UTC
I work with OpenGL graphics library and I wanted to draw scene in GIMP before
put it in my vertex array, but found that it's impossible to change behavior of
the rulers. For example, I need to make the begining of Y-axis to left bottom
corner as it expected in OpenGL. Other words, I should draw image fliped or
count every vertex myself and then count it again during I copying it in my
array. It is unnecessary hedache. IMHO, such solid behavior of GIMP rulers is
serious miss-feature.
Comment 4 Sven Neumann 2005-09-19 19:32:50 UTC
Vitali, are you volunteering to implement this missing feature?
Comment 5 Joao S. O. Bueno 2005-12-23 03:38:07 UTC
I am taking a look on this.
I guess it is fine to add new "hruler_offset" and  "vruler_offset"  to the gimpimage structure.
(I can only think of this as a  image property, BTW.)

But I found this issue: Internally the GIMP makes all it's stuff considering 0,0 the upper left corner of the image. Changing the rulers and status bar to display the desried offset, withotu messing with the internal coordiante system is easy - but could become inconsistent in some cases.

OTOH, changing everything internally would be changing really a lot of things (including all the image boundary checks in all the program). Plug'ins  would break (I guess).

So, I'd rather do this as "faking" the offsets on the status bar, rulers, info window and a few other places. IMHO it is either that or WONTFIX.  Mitch, Sven, Bill, Everybody... what do you say?

Comment 6 Michael Natterer 2005-12-23 09:56:54 UTC
I don't think that we are going to change the image coordinate system,
so adding such members to GimpImage would be wrong. It's IMHO a display
thing, so the offsets would live in GimpDisplayShell. There are also
central functions which are used to translate between image and display
space, so this change may be easier than it looks.
Comment 7 invid 2006-09-01 00:22:22 UTC
This is one of the features that keeps me from using Gimp heavily, I do a lot of fine tuned images - web based images etc where they need to conform to standards down to the pixel etc.

It would seem that this could just be 'faked' since it is basically a visual tool as opposed to something that affects the image itself etc.
Comment 8 Sven Neumann 2006-09-01 06:17:54 UTC
We are not at all opposed to this change. If it is important for you, you could try to motivate someone who can code to implement it for you and contribute that change.
Comment 9 Christopher Howard 2009-08-03 23:07:23 UTC
I'd be willing to look into this, but I'm kind of new around here and it doesn't look this this bug report has been touched for a few years. Any recent information or related discussions I should be aware of?
Comment 10 Christopher Howard 2009-08-04 02:46:48 UTC
I've looked at the code a little more, and it seems to me that this enhancement is doable. I officially volunteer to work on it.

Fortunately, the fundamental ruler code is fairly well sequestered off from the rest of the code. I think that development should look something like this:

 1. Modify gimpruler widget structures and functions to handle offset values (libwidgets/gimpruler.c and libwidgets/gimpruler.h)

 2. Modify the code elsewhere than utilizes the gimpruler functions (haven't looked into this much yet).

 3. Add menu item for setting the ruler offsets.

However, this does raise additional issues we will have to think about: If it is possible to change the offset (zero-point) of the ruler, perhaps it should also be possible to change the small x,y coordinate display at the bottom left of the main window, so that it displays the same values as the ruler. (Input anyone?) Also, certainly tools display coordinates independently of the ruler: so, for example, if the user changed only his ruler, his measuring tool would still be displaying the absolute coordinates on the image.
Comment 11 Sven Neumann 2009-08-04 18:34:35 UTC
We should definitely discuss this first on the mailing-list. If we do this, then it needs to be done properly and affect all places that display coordinates. The question really is, do we want to open this can of worms? If so, how is this best done and how does the user interface for it look like? All this should be discussed on the mailing-list.
Comment 12 Christopher Howard 2009-08-04 22:09:54 UTC
It seems like a pretty reasonable feature request to me. The person who initially requested the enhancement provided good, practical reasons how it would be beneficial. And I can't imagine that he would be the only web developer on the planet who would benefit from being able to set the zero point.

I know you guys aren't trying to be simply a Photoshop clone, but if this feature has been in Photoshop for half a decade and the end-users like it, it is probably one we should be thinking seriously about.

Of course, I'll take whatever discussion or guidance I can get before diving into this.
Comment 13 Martin Nordholts 2009-08-05 05:32:50 UTC
Hi Christopher and thank you for you showed interest, we need any help we can get from programmers.

What Sven is saying is simply that if we do this, it must be done properly. GIMP has several severe UI problems and we don't want to make things worse. UI design is not a trivial issue, therefore, we suggest that a UI solution is worked out on the gimp-developer mailing list before code is written.

If you are so inclined, you are of course free to write a patch and solve this in whatever way you like, but if you do that then there is a risk that you used an approach that we didn't like, and your work would be rejected.

Don't get me wrong, we very much appreciate your help, but we still need to ensure high quality solutions and code.
Comment 14 Michael Schumacher 2009-11-02 20:31:23 UTC
*** Bug 600452 has been marked as a duplicate of this bug. ***
Comment 15 GNOME Infrastructure Team 2018-05-24 11:22:41 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/118.