Discussion:
Coordinate system fix
(too old to reply)
Krzysztof Kosiński
2010-04-03 17:13:59 UTC
Permalink
Hello

In revision 9288 I fixed the inverted coordinate system bug, starting
from a patch by Thomas Holder.
https://bugs.launchpad.net/inkscape/+bug/170049

While this is a rather invasive change, fixing bugs caused by removing
the coordinate inversion is simple (often it boils down to tweaking a
single line of code), so I think we'll manage to fix any remaining
regressions before the release.

Regards, Krzysztof
Jon Cruz
2010-04-03 17:47:35 UTC
Permalink
On Apr 3, 2010, at 10:13 AM, Krzysztof Kosiński wrote:

> Hello
>
> In revision 9288 I fixed the inverted coordinate system bug, starting
> from a patch by Thomas Holder.
> https://bugs.launchpad.net/inkscape/+bug/170049
>
> While this is a rather invasive change, fixing bugs caused by removing
> the coordinate inversion is simple (often it boils down to tweaking a
> single line of code), so I think we'll manage to fix any remaining
> regressions before the release.

Thanks for cleaning that one up. I know quite a lot had gotten fixed in the last years, especially with the lib2geom split, etc.

Oh, while you were in there did you happen to get a feel for how changing our DPI might work? Originally it was hardcoded into individual calculations, often as ".8", "0.8" or "1.25". We had been trying to at least minimize the use of those.

The last few times I've discussed this with Mental, he had been saying that we should be close to being able to do these both. And if you've just run through that coord inversion changeset you're probably best with things fresh in mind to be able to look at DPI.

Thanks.
Krzysztof Kosiński
2010-04-03 17:58:49 UTC
Permalink
W dniu 3 kwietnia 2010 19:47 użytkownik Jon Cruz <***@joncruz.org> napisał:
> Oh, while you were in there did you happen to get a feel for how changing our DPI might work? Originally it was hardcoded into individual calculations, often as ".8", "0.8" or "1.25". We had been trying to at least minimize the use of those.

Unfortunately DPI handling is not very related to desktop coordinates.
When I worked on the patch, I found only 1 place (related to bitmap
copy) where I found any DPI-related code.

Additionally, I'm not sure how exactly DPI handling should work.
Should this be a global setting of the document, or something that
reflects the monitor's resolution? Some blueprint would be useful.

Regards, Krzysztof
Jon Cruz
2010-04-03 21:00:14 UTC
Permalink
On Apr 3, 2010, at 10:58 AM, Krzysztof Kosiński wrote:

> W dniu 3 kwietnia 2010 19:47 użytkownik Jon Cruz <***@joncruz.org> napisał:
>> Oh, while you were in there did you happen to get a feel for how changing our DPI might work? Originally it was hardcoded into individual calculations, often as ".8", "0.8" or "1.25". We had been trying to at least minimize the use of those.
>
> Unfortunately DPI handling is not very related to desktop coordinates.
> When I worked on the patch, I found only 1 place (related to bitmap
> copy) where I found any DPI-related code.

Well, there are a few different ways DPI affects things. One is in bitmap import, but another is with display and matrices.

For the one most related to the axis inversion, one would want a display with a high pixel resolution result in more actual pixels assigned per px than one with a low resolution display. Common display PPI are 72, 90, 96 and 144. CSS2, CSS2.1 address this, and CSS3 might complicate it a bit more.

Then we would want a *per document* DPI setting that might involve a viewBox, etc. Accounting for that might be a different factor.

> Additionally, I'm not sure how exactly DPI handling should work.
> Should this be a global setting of the document, or something that
> reflects the monitor's resolution? Some blueprint would be useful.


I'll get some stuff together on the wiki for the big picture. In the mean time you might look at the zoom correction factor in the "Interface" preferences tab. That is part of a work-around for not detecting/accounting for physical monitor PPI. I think I also saw a "1.25" in a win32 cpp file, but I've not chased down its impact yet.

Oh, and I've already been dealing with monitor query stuff for the color profiles. I'll look to see what I can give you for physical monitor DPI, especially for multi-monitor setups. (And we might see a lot more of those, as the iPad, iPhone and iPod touch now have an app that makes them work as an additional monitor)
Joshua A. Andler
2010-04-03 20:30:36 UTC
Permalink
On Sat, 2010-04-03 at 19:13 +0200, Krzysztof Kosiński wrote:
> Hello
>
> In revision 9288 I fixed the inverted coordinate system bug, starting
> from a patch by Thomas Holder.
> https://bugs.launchpad.net/inkscape/+bug/170049
>
> While this is a rather invasive change, fixing bugs caused by removing
> the coordinate inversion is simple (often it boils down to tweaking a
> single line of code), so I think we'll manage to fix any remaining
> regressions before the release.

3D Box needs at least one fix.

When Angle Y is toggled, the lines should be going up, not down. I tried
to do a quick search on where the problem might lie, but 3dbox is quite
separated code-wise.

Cheers,
Josh
Krzysztof Kosiński
2010-04-03 21:47:52 UTC
Permalink
W dniu 3 kwietnia 2010 22:30 użytkownik Joshua A. Andler
<***@gmail.com> napisał:
> 3D Box needs at least one fix.
>
> When Angle Y is toggled, the lines should be going up, not down. I tried
> to do a quick search on where the problem might lie, but 3dbox is quite
> separated code-wise.

Uh oh, it turns out 3D Box stored desktop coordinates in the XML!

Regards, Krzysztof
Krzysztof Kosiński
2010-04-03 21:45:26 UTC
Permalink
W dniu 3 kwietnia 2010 23:36 użytkownik <***@ewi.utwente.nl> napisał:
> I feel this change is too invasive so close to release. Many things might break by this. Perhaps they are easy to fix, but they might not be so easy to discover.
> To start: we will have to test all output extensions.
> (pdf export is broken for example)

Are you sure? It works for me, including the LaTeX option.

As long as something doesn't touch SPDesktop, it should be fine. If it
correctly uses sp_item_i2d_affine, desktop->doc2dt, etc. it doesn't
require fixing either. The only things that require fixing are
hardcoded Y axis flips when translating between SVG coordinates and
desktop coordinates.

Regards, Krzysztof
J***@ewi.utwente.nl
2010-04-03 22:12:10 UTC
Permalink
> -----Original Message-----
> From: Krzysztof Kosiński [mailto:***@gmail.com]
> Sent: zaterdag 3 april 2010 23:45
> To: Engelen, J.B.C. (Johan)
> Cc: inkscape-***@lists.sourceforge.net
> Subject: Re: [Inkscape-devel] Coordinate system fix
>
> W dniu 3 kwietnia 2010 23:36 użytkownik
> <***@ewi.utwente.nl> napisał:
> > I feel this change is too invasive so close to release.
> Many things might break by this. Perhaps they are easy to
> fix, but they might not be so easy to discover.
> > To start: we will have to test all output extensions.
> > (pdf export is broken for example)
>
> Are you sure? It works for me, including the LaTeX option.
>
> As long as something doesn't touch SPDesktop, it should be
> fine. If it correctly uses sp_item_i2d_affine,
> desktop->doc2dt, etc. it doesn't require fixing either. The
> only things that require fixing are hardcoded Y axis flips
> when translating between SVG coordinates and desktop coordinates.

Confirmed on Jabber. Exporting PDF with "export area is drawing" set does not work correctly and exports wrong area. (also not LaTeX, but that's related).
Krzysztof Kosiński
2010-04-03 22:52:11 UTC
Permalink
W dniu 4 kwietnia 2010 00:12 użytkownik <***@ewi.utwente.nl> napisał:
> Confirmed on Jabber.  Exporting PDF with "export area is drawing" set does not work correctly and exports wrong area. (also not LaTeX, but that's related).

Fixed in 9290.

The 3DBox regression is rather complex. The perspective is saved to
XML in desktop coordinates rather than SVG document coordinates, and
as a result 3D boxes are inverted on the Y-axis when loaded from a
file created by a pre-switch version of Inkscape. The fact that I have
no idea what the saved values mean doesn't help. :)

Places to look:
- box3d.cpp
- persp3d.cpp
- proj_pt.cpp
- transf_mat_3x4.cpp

If someone could tell me what actually determines where the vanishing
points are shown, it would help. (Maybe I'll figure it out on my own
tommorow.)

Regards, Krzysztof
Jasper van de Gronde
2010-04-04 09:22:44 UTC
Permalink
Krzysztof Kosiński wrote:
> W dniu 4 kwietnia 2010 00:12 użytkownik <***@ewi.utwente.nl> napisał:
>> Confirmed on Jabber. Exporting PDF with "export area is drawing" set does not work correctly and exports wrong area. (also not LaTeX, but that's related).
>
> Fixed in 9290.
>
> The 3DBox regression is rather complex. The perspective is saved to
> XML in desktop coordinates rather than SVG document coordinates, and
> as a result 3D boxes are inverted on the Y-axis when loaded from a
> file created by a pre-switch version of Inkscape. The fact that I have
> no idea what the saved values mean doesn't help. :)
>
> Places to look:
> - box3d.cpp
> - persp3d.cpp
> - proj_pt.cpp
> - transf_mat_3x4.cpp
>
> If someone could tell me what actually determines where the vanishing
> points are shown, it would help. (Maybe I'll figure it out on my own
> tommorow.)

My guess would that it uses homogenous coordinates, 2D for the
perspective definition and 3D for the actual cube. This means that for
the perspective definition there are 3 coordinates given: the x, y and
"w" values for each of the three vanishing points. The actual location
of the vanishing point is then given by (x,y)/w, if w is zero the
vanishing point is usually taken to lie infinitely far along the ray
(x,y)*t (probably relative to persp3d-origin?).

For the 3d box itself corner0 appears to be the top-left-back corner and
corner7 the opposite corner (bottom-right-front). Again these are using
homogenous coordinates (but now in 3D, so with 4 values per point). The
scale is related to the perspective definition. For example, if the
origin is set to (0,0) and w=0 for all vanishing points then (x,y,z) in
the box corresponds to x*vp_x+y*vp_y+z*vp_z (only taking the (x,y) part
of the vanishing points).
Krzysztof Kosiński
2010-04-05 00:46:52 UTC
Permalink
I fixed guidelines, text cursor and zooming with the mouse.

I have a partial fix for 3D Box (attached), but:

1. The height of the box is wrong when the Y axis has an infinite
vanishing point.
2. Faces are mixed up when the box is selected for editing with the 3D Box tool.

It is not a case of the coordinates in box3d.cpp being inverted on the
Y axis. Apparently the code was depending on the "chirality" of the
coordinate system, and flipping the Y axis also flips the chirality.
Anyone knows how this could be fixed?

Regards, Krzysztof
Jon Cruz
2010-04-05 01:15:54 UTC
Permalink
On Apr 4, 2010, at 5:46 PM, Krzysztof Kosiński wrote:

> It is not a case of the coordinates in box3d.cpp being inverted on the
> Y axis. Apparently the code was depending on the "chirality" of the
> coordinate system, and flipping the Y axis also flips the chirality.
> Anyone knows how this could be fixed?


For 3D graphics I think I've generally heard that referred to as "handedness".

http://en.wikipedia.org/wiki/Cartesian_coordinate_system#Orientation_and_handedness

Generally the first thing to do is determine if what you have is based on the right-hand rule or the left-hand rule.
http://en.wikipedia.org/wiki/Right-hand_rule

I also seem to recall that flipping *two* axes are usually done to flip the handedness. So changing just one might be causing stranger results.

Let me know if those terms don't point to some concrete information you can use.
~suv
2010-04-05 04:58:01 UTC
Permalink
On 5/4/10 02:46, Krzysztof Kosiński wrote:
> I fixed guidelines, text cursor and zooming with the mouse.

Inkscape 0.47+devel r9295:

Guides are wrongly placed after resizing the page to content. When
undoing the page resize (Edit > Undo) the guides are displaced even
further from the original location.

Both works as expected in Inkscape 0.47: Guides keep their position
relative to the objects after page resize and stay there when undoing a
page resize.


~suv
J***@ewi.utwente.nl
2010-04-03 21:36:22 UTC
Permalink
> -----Original Message-----
> From: Krzysztof Kosiński [mailto:***@gmail.com]
> Sent: zaterdag 3 april 2010 19:14
> To: inkscape-devel
> Subject: [Inkscape-devel] Coordinate system fix
>
> Hello
>
> In revision 9288 I fixed the inverted coordinate system bug,
> starting from a patch by Thomas Holder.
> https://bugs.launchpad.net/inkscape/+bug/170049
>
> While this is a rather invasive change, fixing bugs caused by
> removing the coordinate inversion is simple (often it boils
> down to tweaking a single line of code), so I think we'll
> manage to fix any remaining regressions before the release.

I feel this change is too invasive so close to release. Many things might break by this. Perhaps they are easy to fix, but they might not be so easy to discover.
To start: we will have to test all output extensions.
(pdf export is broken for example)

Cheers,
Johan
~suv
2010-04-04 01:26:52 UTC
Permalink
On 3/4/10 19:13, Krzysztof Kosiński wrote:

> In revision 9288 I fixed the inverted coordinate system bug, starting
> from a patch by Thomas Holder.
> https://bugs.launchpad.net/inkscape/+bug/170049
>
> While this is a rather invasive change, fixing bugs caused by removing
> the coordinate inversion is simple (often it boils down to tweaking a
> single line of code), so I think we'll manage to fix any remaining
> regressions before the release.

Guides are wrongly positioned when opening older documents [1] in
current builds (r9290):

- objects previously aligned to guides no longer are because horizontal
guides are positioned relative to the new origin (e.g. from the upper
left corner down) but the objects themselves keep their position.
- diagonal (45°) guidelines seem to be displaced even more then
horizontal ones (not seen in the attached test file)
- vertical guides have their origins moved

My expectation is that after changing the ui coordinate system the
guides are still aligned with / stay at the same position relative to
the objects.


~suv

[1] test file attached
bulia byak
2010-04-05 14:37:00 UTC
Permalink
2010/4/3 Krzysztof Kosiński <***@gmail.com>:
> Hello
>
> In revision 9288 I fixed the inverted coordinate system bug, starting
> from a patch by Thomas Holder.
> https://bugs.launchpad.net/inkscape/+bug/170049

This is very well, but I bet there are people who would want the old
orientation back. Any chance of making it an option?

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Bryan Hoyt | Brush Technology
2010-04-05 19:27:17 UTC
Permalink
>
> This is very well, but I bet there are people who would want the old
> orientation back. Any chance of making it an option?
>

Fewer options is almost always better, all else being equal. When it comes
down to something like this (upwards vs. downwards) that doesn't affect the
drawing or its appearance on the screen, and doesn't limit what's possible
or convenient with Inkscape, then consistency with the standard should be
(as it has been) the only determining factor.

For new users who expect it to work the opposite way, an option wouldn't
really help their first impressions or their learning curve.

For old users who are used to an existing way of working, it's not worth
keeping around options to accommodate everyone's old habits.

I'm sure we could find people who would like to see every possible
combination of axis orientations possible (for one reason or another) --
imagine if we had an option for each one.

Just my thoughts,
Bryan
Joshua A. Andler
2010-04-05 19:45:08 UTC
Permalink
On Tue, 2010-04-06 at 07:27 +1200, Bryan Hoyt | Brush Technology wrote:
> This is very well, but I bet there are people who would want
> the old
> orientation back. Any chance of making it an option?
>
>
> Fewer options is almost always better, all else being equal. When it
> comes down to something like this (upwards vs. downwards) that doesn't
> affect the drawing or its appearance on the screen, and doesn't limit
> what's possible or convenient with Inkscape, then consistency with the
> standard should be (as it has been) the only determining factor.

Fewer options is not almost always better. Fewer options is almost
always more limiting for some group of users. It's also been my
experience that bulia tends to have very good judgment about when such
options are desirable.

Cheers,
Josh
Bryan Hoyt | Brush Technology
2010-04-05 19:58:46 UTC
Permalink
>
> Fewer options is not almost always better. Fewer options is almost
> always more limiting for some group of users.


Ok, point taken -- although I think care needs to be taken not to build so
many extra options in (just in case someone wants it) that it becomes
a) very difficult for new users to discover features, because there's so
much less-than-useful stuff to scan through, and
b) very hard for new & old users to find anything (think MS Word, which has
so many, albeit useful, menu items that you can find your favorite feature
more quickly by doing a web search than by scanning through all the
menus/prefs)

I'll happily concede that bulia tends to have very good judgement on these
things -- I'm relatively new around here, and bulia is clearly experienced.

Either way, I think it would be useful to have a more concrete use-case than
"I bet there are people who would want the old orientation back" before
adding a preference for something. Bulia, do you have any use-cases or
actual people in mind for this preference?

PS. Is it OK on this list to put my 2c in on things like this when I'm not
actually involved in development? Let me know if I'm just getting in the way
of a well-oiled process (http://yellow.bikeshed.com/)

- Bryan
Ted Gould
2010-04-05 20:34:46 UTC
Permalink
On Tue, 2010-04-06 at 07:58 +1200, Bryan Hoyt | Brush Technology wrote:
> PS. Is it OK on this list to put my 2c in on things like this when I'm
> not actually involved in development? Let me know if I'm just getting
> in the way of a well-oiled process (http://yellow.bikeshed.com/)

Of course. I think that one of the things that makes Inkscape strong is
real users giving opinions and use cases on the mailing list. But, be
prepared to defend them! :)

> Fewer options is not almost always better. Fewer options is
> almost
> always more limiting for some group of users.
>
>
> Ok, point taken -- although I think care needs to be taken not to
> build so many extra options in (just in case someone wants it) that it
> becomes
> a) very difficult for new users to discover features, because there's
> so much less-than-useful stuff to scan through, and
> b) very hard for new & old users to find anything (think MS Word,
> which has so many, albeit useful, menu items that you can find your
> favorite feature more quickly by doing a web search than by scanning
> through all the menus/prefs)

I think that one of the things we suffer from is having too many
settings. And part of that is that we don't have a good separation
between advanced settings and things you're likely to want to change. I
already find the preferences dialog daunting. That being said...

> Either way, I think it would be useful to have a more concrete
> use-case than "I bet there are people who would want the
> old orientation back" before adding a preference for something. Bulia,
> do you have any use-cases or actual people in mind for this
> preference?

Yeah, different types of drawing have vastly different traditions. It's
hard to follow things like manuals and tutorials on design if you can't
match their origin. I've personally had every set of I could think of
suggested for where Inkscape should put the origin. People with a math
background tend to like it on the bottom left so all the numbers are
"positive" in their book. Computer graphics people like it in the upper
left because that's how monitors scan (or used to, in some cases today).
Print is typically bottom left.

I think that there's enough different traditions here to warrant a
preference unless we're going to only support one type of artist (which
I don't believe we want to do). Though, I do believe it should be a
document preference not a global one.

--Ted
Alexandre Prokoudine
2010-04-05 21:21:14 UTC
Permalink
On 4/6/10, Ted Gould wrote:

> Print is typically bottom left.

Er... Since when? :)

Print has been top left for ages.

Alexandre
Ted Gould
2010-04-05 21:59:34 UTC
Permalink
On Tue, 2010-04-06 at 01:21 +0400, Alexandre Prokoudine wrote:
> On 4/6/10, Ted Gould wrote:
> > Print is typically bottom left.
>
> Er... Since when? :)
>
> Print has been top left for ages.

Honestly, I don't know. But I believe that Postscript is bottom left
and PS1 was 1984. So at least since then :) Here's a quick ref I could
find from Google:

http://www.tailrecursive.org/postscript/graphics.html

User space is essentially the same as the first quadrant of the
standard coordinate system used in high school math classes.
Point (0, 0) is in the lower left corner.

Another coordinate system is fonts. Which have 0,0 at the baseline.

--Ted
Thorsten Wilms
2010-04-06 16:20:23 UTC
Permalink
On Mon, 2010-04-05 at 16:59 -0500, Ted Gould wrote:
> On Tue, 2010-04-06 at 01:21 +0400, Alexandre Prokoudine wrote:
> > On 4/6/10, Ted Gould wrote:
> > > Print is typically bottom left.
> >
> > Er... Since when? :)
> >
> > Print has been top left for ages.
>
> Honestly, I don't know. But I believe that Postscript is bottom left
> and PS1 was 1984. So at least since then :)

I think QuarkXpress and Indesign use a top left origin, but I'm not sure
anymore.

Seems Illustrator uses bottom left.

There has been only a single case in my whole life where an origin that
wasn't top left seemed useful :)

If an option, it should be per document, as the merit of various origins
depends on the specific case.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/
Alexandre Prokoudine
2010-04-05 20:36:29 UTC
Permalink
On 4/5/10, Joshua A. Andler wrote:

> Fewer options is not almost always better. Fewer options is almost
> always more limiting for some group of users.

When you try to please everyone, usually you please nobody :)

> It's also been my experience that bulia tends to have very good
> judgment about when such options are desirable.

In this case it sounds like a terrible overhead. If there can be a
nice abstraction, then it might work, but if not, chances are that we
will break a lot of things for 0.47 and probably even beyond.

Right now we are finally compatible with the rest of the stack
(Scribus and GIMP, not speaking about people coming with AI and CDR
background) at the cost of being less accessible for our technical
drawing users. Whatever you decide, please don't break everything :)

Alexandre
Jon Cruz
2010-04-06 01:02:00 UTC
Permalink
On Apr 5, 2010, at 1:36 PM, Alexandre Prokoudine wrote:

> In this case it sounds like a terrible overhead. If there can be a
> nice abstraction, then it might work, but if not, chances are that we
> will break a lot of things for 0.47 and probably even beyond.

Also if it is nicely abstracted we can also rotate the canvas.

Artists really like to turn the paper as they draw, and most recent closed apps use rings and sliders on drawing tablets to do just that.
Chris Mohler
2010-04-06 01:14:09 UTC
Permalink
On Mon, Apr 5, 2010 at 8:02 PM, Jon Cruz <***@joncruz.org> wrote:
> Artists really like to turn the paper as they draw

+1 billion.

I often turn the paper upside-down or sideways when drawing in
meatspace. It's an easy way to judge the weight of a composition...

Anecdote: I used to paint on stage with a band - I would paint for a
while, then rotate 90 degrees, paint some more, repeat. Lots of fun
can be had with creating images that can be viewed from different
perspectives.

Just 0.02...

Chris
Bryan Hoyt | Brush Technology
2010-04-06 02:55:58 UTC
Permalink
>
> Also if it is nicely abstracted we can also rotate the canvas


Wow, that would be cool.
Jason Smith
2010-04-05 20:54:48 UTC
Permalink
So I am not crazy! I was drawing in Inkscape and then moving the resulting picture into XHTML (HTML5) markup. The 0,0 point is the upper left corner of the visual "page." It's a little awkward, but I can work with it. Is that what this feature is attempting to address?

Is there a *better* way to see the drawing, perhaps without page boundaries, so that 0,0 is at the center (visually) when drawing, and corresponds to what I am really going after, which is the center of rotation? I have the Inkscape book, but I didn't see anything in there (I might have missed it).

Jason Smith
________________________________
From: Bryan Hoyt | Brush Technology [***@brush.co.nz]
Sent: Monday, April 05, 2010 1:27 PM
To: bulia byak
Cc: inkscape-devel
Subject: Re: [Inkscape-devel] Coordinate system fix

This is very well, but I bet there are people who would want the old
orientation back. Any chance of making it an option?

Fewer options is almost always better, all else being equal. When it comes down to something like this (upwards vs. downwards) that doesn't affect the drawing or its appearance on the screen, and doesn't limit what's possible or convenient with Inkscape, then consistency with the standard should be (as it has been) the only determining factor.

For new users who expect it to work the opposite way, an option wouldn't really help their first impressions or their learning curve.

For old users who are used to an existing way of working, it's not worth keeping around options to accommodate everyone's old habits.

I'm sure we could find people who would like to see every possible combination of axis orientations possible (for one reason or another) -- imagine if we had an option for each one.

Just my thoughts,
Bryan
~suv
2010-04-05 20:04:39 UTC
Permalink
On 5/4/10 16:37, bulia byak wrote:
> 2010/4/3 Krzysztof Kosiński <***@gmail.com>:
>> In revision 9288 I fixed the inverted coordinate system bug, starting
>> from a patch by Thomas Holder.
>> https://bugs.launchpad.net/inkscape/+bug/170049
>
> This is very well, but I bet there are people who would want the old
> orientation back. Any chance of making it an option?

I would definitely prefer to make this an option, see
<https://bugs.launchpad.net/inkscape/+bug/170049/comments/32>

Using Inkscape for technical drawings and diagrams will be more
difficult with the changed orientation of the coordinate system. To me -
having a background in CAAD - it doesn't seem logical (besides adhering
to the SVG standards).

~suv
Krzysztof Kosiński
2010-04-06 00:46:01 UTC
Permalink
W dniu 5 kwietnia 2010 22:04 użytkownik ~suv
<suv-***@users.sourceforge.net> napisał:
> Using Inkscape for technical drawings and diagrams will be more
> difficult with the changed orientation of the coordinate system. To me -
> having a background in CAAD - it doesn't seem logical (besides adhering
> to the SVG standards).

Adhering to the SVG standard at the DOM (SP tree) level looks logical
to me. We can then implement a different mechanism for specifying the
coordinate system to be shown in the UI, but at the DOM level
everything should be in SVG coordinates. Essentially the document /
desktop split was a design error.

Can anyone look into the 3D Box regression? I have run out of ideas on
how to fix it. If nobody figures this out, we have two options: a)
leave 3D Box broken, forcing the users to V-flip them after opening
the document; b) revert the fix. I don't think a) is going to sit well
with users.

Note that this is essentially a design error in the guides and the 3D
Box tool, and we'll have to fix it sooner or later. Probably the
approach I've taken (convert coordinates at the DOM level) is wrong,
and I should handle this in sp_document_create by fixing the incorrect
values in the XML as the document is loaded. This would fix the guides
+ undo issue.

Regards, Krzysztof
Jon Cruz
2010-04-06 01:12:11 UTC
Permalink
On Apr 5, 2010, at 5:46 PM, Krzysztof Kosiński wrote:

> Adhering to the SVG standard at the DOM (SP tree) level looks logical
> to me. We can then implement a different mechanism for specifying the
> coordinate system to be shown in the UI, but at the DOM level
> everything should be in SVG coordinates. Essentially the document /
> desktop split was a design error.

Well, close.

I'd say that you're right about keeping the DOM level clean. And then for the document/desktop split we just need a *clean* definition and separation.

That is, we need to make it easy to work with multiple views ("desktops") on a single document with everything consistent. Allowing for rotation is a view-specific twist that I think can help with considering where and how to separate coords.
Krzysztof Kosiński
2010-04-06 11:52:57 UTC
Permalink
2010/4/6 Jon Cruz <***@joncruz.org>:
> That is, we need to make it easy to work with multiple views ("desktops") on a single document with everything consistent. Allowing for rotation is a view-specific twist that I think can help with considering where and how to separate coords.

I think being able to create multiple desktops for the same document
is a huge misfeature. It introduces considerable additional complexity
for little benefit. All applications I have ever used work like this:
1. You open a document.
2. The document stays in memory until you save and / or close it.
3. If you open the same document in a different window, those two
copies are not connected in any way.
4. If you save one of them, the second window can complain that the
file was modified, and offer to reload in such case (if the app is
smart enough). If you don't reload, the document should be considered
unsaved, e.g. the Save toolbar item should bring up the Save As
dialog.

W dniu 6 kwietnia 2010 03:21 użytkownik ~suv
<suv-***@users.sourceforge.net> napisał:
> Inkscape 0.47+devel r9295:
>
> Newly created horizontal guides don't stay where they are dropped but
> immediately move to the mirrored location. Origins of vertical guides
> move to the mirrored position. Diagonal guides can't be positioned as
> intended either, guides converted from objects don't align with the objects.

It's because the "namedview" element is stored without conversion to
SVG coordinates.

Here's how I would like to fix this and the 3D Box problem.
1. Introduce a file called document-compatibility.cpp.
2. Introduce versioning of documents' editing information. The editing
info version will not be tied to the Inkscape version - it will be
just a number. We start at editing info version 0, which is defined as
what Inkscape 0.47 uses. Every subsequent version is defined as a
series of transformations from version 0.
3. document-compatibility.cpp contains a function called
upgrade_document(), or something like this. It takes an
Inkscape::XML::Node to the root of the SVG and upgrades the document
to the latest editing info version.
4. upgrade_document() reads the editing info version from an extra
attribute in the SVG root (it can be called
inkscape:document-version). It executes a series of transformations on
the XML document to bring it in line with what the current SP tree
expects.
5. When you want to make a change in the XML, you bump the current
version by one, add the necessary XML transformations and update all
relevant SP tree code to only recognize the new XML. If you did
everything correct, the SP tree code doesn't need to know about any
document format other than the latest one.

Why this is good:
1. Upgrade is performed before the SP tree is constructed. This means
the SP tree doesn't have to retain backwards compatibility junk
indefinitely.
2. We have a well defined backwards compatibility mechanism, rather
than a collection of hacks.
3. We have a clear way forward to fix long time blunders like flowtext.

Why this could be bad:
1. No semantic help from the SP tree.
2. ???

Regards, Krzysztof
Aaron Spike
2010-04-06 12:18:31 UTC
Permalink
Krzysztof Kosiński wrote:
> 2010/4/6 Jon Cruz <***@joncruz.org>:
>> That is, we need to make it easy to work with multiple views
>> ("desktops") on a single document with everything consistent.
>> Allowing for rotation is a view-specific twist that I think can
>> help with considering where and how to separate coords.
>
> I think being able to create multiple desktops for the same document
> is a huge misfeature. It introduces considerable additional
> complexity for little benefit.

A commonly used benefit would be viewing the document at two zoom levels
at the same time. A user can adjust a drawing at a high zoom level and
see how it affects the overall look of the image without repeatedly
having to change zoom level (very frustrating). A long time ago Jon did
a mockup of combining multiple views in a single window:

http://wiki.inkscape.org/wiki/index.php/SplitPaneUI

Just as "Other software does this" isn't the best argument in favor of a
feature, neither is "Other software doesn't do this" always the best
argument against a feature. For some reason comparative arguments tend
to detract from the main point: the affect on the user. Whether or not
other software allows it, providing multiple views of a document can
make a user more efficient.

Aaron Spike
Thomas Ibbotson
2010-04-06 12:30:26 UTC
Permalink
On 6 April 2010 13:18, Aaron Spike <***@ekips.org> wrote:
> Krzysztof Kosiński wrote:
>> 2010/4/6 Jon Cruz <***@joncruz.org>:
>>> That is, we need to make it easy to work with multiple views
>>> ("desktops") on a single document with everything consistent.
>>> Allowing for rotation is a view-specific twist that I think can
>>> help with considering where and how to separate coords.
>>
>> I think being able to create multiple desktops for the same document
>> is a huge misfeature. It introduces considerable additional
>> complexity for little benefit.
>
>
> Just as "Other software does this" isn't the best argument in favor of a
> feature, neither is "Other software doesn't do this" always the best
> argument against a feature. For some reason comparative arguments tend
> to detract from the main point: the affect on the user. Whether or not
> other software allows it, providing multiple views of a document can
> make a user more efficient.
>

Also, other software does do this. For example in gvim you can split
your window vertically and horizontally, or add a new tab and have 2
copies of the same file with different views, and any changes made in
one window are seen in the other.

Tom
Krzysztof Kosiński
2010-04-06 13:20:40 UTC
Permalink
2010/4/6 Aaron Spike <***@ekips.org>:
>
> A commonly used benefit would be viewing the document at two zoom levels
>  at the same time. A user can adjust a drawing at a high zoom level and
> see how it affects the overall look of the image without repeatedly
> having to change zoom level (very frustrating). A long time ago Jon did
> a mockup of combining multiple views in a single window:
>
> http://wiki.inkscape.org/wiki/index.php/SplitPaneUI

This mockup is OK. Creating two or more SPCanvas / NRArenas per
document is good. What I'm against is creating two SPDesktops that
edit the same SPDocument. It's just wrong and unexpected for users,
and it makes correctly implementing shape editing tools extremely
tedious.

Regards, Krzysztof
Jasper van de Gronde
2010-04-06 12:22:43 UTC
Permalink
Might I echo Johan's earlier comment about this possibly being a bit
much to squeeze in for this release? Obviously you (and others) have
done great work on getting Inkscape's coordinate system in better shape,
but it appears there are at least one or two major problems which need a
lot more changes to really get them right.

Krzysztof Kosiński wrote:
> W dniu 6 kwietnia 2010 03:21 użytkownik ~suv
> <suv-***@users.sourceforge.net> napisał:
>> Inkscape 0.47+devel r9295:
>>
>> Newly created horizontal guides don't stay where they are dropped but
>> immediately move to the mirrored location. Origins of vertical guides
>> move to the mirrored position. Diagonal guides can't be positioned as
>> intended either, guides converted from objects don't align with the objects.
>
> It's because the "namedview" element is stored without conversion to
> SVG coordinates.
>
> Here's how I would like to fix this and the 3D Box problem.
> 1. Introduce a file called document-compatibility.cpp.
> 2. Introduce versioning of documents' editing information. The editing
> info version will not be tied to the Inkscape version - it will be
> just a number. We start at editing info version 0, which is defined as
> what Inkscape 0.47 uses. Every subsequent version is defined as a
> series of transformations from version 0.
> 3. document-compatibility.cpp contains a function called
> upgrade_document(), or something like this. It takes an
> Inkscape::XML::Node to the root of the SVG and upgrades the document
> to the latest editing info version.
> 4. upgrade_document() reads the editing info version from an extra
> attribute in the SVG root (it can be called
> inkscape:document-version). It executes a series of transformations on
> the XML document to bring it in line with what the current SP tree
> expects.
> 5. When you want to make a change in the XML, you bump the current
> version by one, add the necessary XML transformations and update all
> relevant SP tree code to only recognize the new XML. If you did
> everything correct, the SP tree code doesn't need to know about any
> document format other than the latest one.
>
> Why this is good:
> 1. Upgrade is performed before the SP tree is constructed. This means
> the SP tree doesn't have to retain backwards compatibility junk
> indefinitely.
> 2. We have a well defined backwards compatibility mechanism, rather
> than a collection of hacks.
> 3. We have a clear way forward to fix long time blunders like flowtext.
>
> Why this could be bad:
> 1. No semantic help from the SP tree.
> 2. ???
>
> Regards, Krzysztof
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
bulia byak
2010-04-06 13:33:12 UTC
Permalink
2010/4/6 Krzysztof Kosiński <***@gmail.com>:
> I think being able to create multiple desktops for the same document
> is a huge misfeature. It introduces considerable additional complexity
> for little benefit.

It is just a bonus we get for implementing using the
model-view-controller architecture. One model, multiple views and
controllers.

Yes, it is considerable additional complexity when each control must
watch the relevant part of document that can be changed, without
warning, in another view. But then, exactly the same watch is needed
for undo anyway: like multiple views, undo can without warning change
any aspect of document from under your feet.

> Here's how I would like to fix this and the 3D Box problem.
> 1. Introduce a file called document-compatibility.cpp.
> 2. Introduce versioning of documents' editing information. The editing
> info version will not be tied to the Inkscape version - it will be
> just a number. We start at editing info version 0, which is defined as
> what Inkscape 0.47 uses. Every subsequent version is defined as a
> series of transformations from version 0.
> 3. document-compatibility.cpp contains a function called
> upgrade_document(), or something like this. It takes an
> Inkscape::XML::Node to the root of the SVG and upgrades the document
> to the latest editing info version.
> 4. upgrade_document() reads the editing info version from an extra
> attribute in the SVG root (it can be called
> inkscape:document-version). It executes a series of transformations on
> the XML document to bring it in line with what the current SP tree
> expects.
> 5. When you want to make a change in the XML, you bump the current
> version by one, add the necessary XML transformations and update all
> relevant SP tree code to only recognize the new XML. If you did
> everything correct, the SP tree code doesn't need to know about any
> document format other than the latest one.

This sounds inevitable, but rather hairy. Why have both
inkscape:version and inkscape:document-version? Can you get what you
need with inkscape:version only?


--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
bulia byak
2010-04-06 13:58:02 UTC
Permalink
2010/4/6 bulia byak <***@gmail.com>:
> Yes, it is considerable additional complexity when each control must
> watch the relevant part of document that can be changed, without
> warning, in another view. But then, exactly the same watch is needed
> for undo anyway: like multiple views, undo can without warning change
> any aspect of document from under your feet.

...and so can XML editor, for that matter.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Krzysztof Kosiński
2010-04-06 14:14:39 UTC
Permalink
W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak
<***@gmail.com> napisał:
> This sounds inevitable, but rather hairy. Why have both
> inkscape:version and inkscape:document-version? Can you get what you
> need with inkscape:version only?

1. Document version changes must be atomic, because the upgrade is
conducted only one time for each type of defect. This means
inkscape:document-version (or inkscape:document-format) can change
several times between two releases.

2. As a result of 1, I would have to parse out the Bazaar revision
from inkscape:version, which is a pain, and introduces a long-distance
dependency I would be *very* uncomfortable with: essentially, the
correct interpretation of old documents depends on the format of the
Bazaar revision string, which is determined by the build system. If
someone decides to change how inkscape:version looks later, things
will unexpectedly fail in really strange ways.

I recognize that introducing the backwards compatibility mechanism
hastily and so late in the release cycle is a bad idea. I also believe
this is the only way to really fix the remaining desktop coordinate
system bugs. Therefore I must revert the coordinate system fixes :(.
We'll look at this again after 0.48 is released.

The fixes will remain available in
lp:~inkscape.dev/inkscape/coords-fix in case someone wants to work on
them.

Regards, Krzysztof
bulia byak
2010-04-06 16:31:43 UTC
Permalink
2010/4/6 Krzysztof Kosiński <***@gmail.com>:
> W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak
> <***@gmail.com> napisał:
>> This sounds inevitable, but rather hairy. Why have both
>> inkscape:version and inkscape:document-version? Can you get what you
>> need with inkscape:version only?
>
> 1. Document version changes must be atomic, because the upgrade is
> conducted only one time for each type of defect. This means
> inkscape:document-version (or inkscape:document-format) can change
> several times between two releases.

But why can't we just fix ALL the defects we find between 0.47 and
0.48 and have just two states of upgrade for <=0.47 and for >=0.48?

> I recognize that introducing the backwards compatibility mechanism
> hastily and so late in the release cycle is a bad idea. I also believe
> this is the only way to really fix the remaining desktop coordinate
> system bugs. Therefore I must revert the coordinate system fixes :(.
> We'll look at this again after 0.48 is released.

OK, so let's make this release real fast then, so we can be back to
development as soon as possible :)


--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Joshua A. Andler
2010-04-06 16:40:08 UTC
Permalink
On Tue, 2010-04-06 at 13:31 -0300, bulia byak wrote:
> > I recognize that introducing the backwards compatibility mechanism
> > hastily and so late in the release cycle is a bad idea. I also believe
> > this is the only way to really fix the remaining desktop coordinate
> > system bugs. Therefore I must revert the coordinate system fixes :(.
> > We'll look at this again after 0.48 is released.
>
> OK, so let's make this release real fast then, so we can be back to
> development as soon as possible :)

I'm all for it, we just need people to get cracking on fixing bugs so
the bug hunt can finish. :) I will do a tally either later today or
tomorrow to see where we stand (unfortunately, not terribly far along
from what I've seen).

Cheers,
Josh
Jon Cruz
2010-04-06 19:52:18 UTC
Permalink
On Apr 6, 2010, at 7:14 AM, Krzysztof Kosiński wrote:

> 2. As a result of 1, I would have to parse out the Bazaar revision
> from inkscape:version, which is a pain, and introduces a long-distance
> dependency I would be *very* uncomfortable with: essentially, the
> correct interpretation of old documents depends on the format of the
> Bazaar revision string, which is determined by the build system. If
> someone decides to change how inkscape:version looks later, things
> will unexpectedly fail in really strange ways.

You're correct in saying we can't use the Bazaar revison. Remember that we have already experienced one fundamental flaw with that... the revision number is an illusion that can change over time. So what was r9296 today might apply to a completely different state of the code next week or next month.
Terry Brown
2010-04-06 20:02:44 UTC
Permalink
On Tue, 6 Apr 2010 12:52:18 -0700
Jon Cruz <***@joncruz.org> wrote:

> You're correct in saying we can't use the Bazaar revison. Remember that we have already experienced one fundamental flaw with that... the revision number is an illusion that can change over time. So what was r9296 today might apply to a completely different state of the code next week or next month.

Ted did apply a flag which is supposed to prevent that from happening, but I wouldn't use the Bazaar revison either. Even if it might be reliable in the current implementation of the inkscape repository, it general it's not.
Jon Cruz
2010-04-06 19:05:30 UTC
Permalink
On Apr 6, 2010, at 4:52 AM, Krzysztof Kosiński wrote:

> 2. Introduce versioning of documents' editing information. The editing
> info version will not be tied to the Inkscape version - it will be
> just a number. We start at editing info version 0, which is defined as
> what Inkscape 0.47 uses. Every subsequent version is defined as a
> series of transformations from version 0.

Do not go with just a simple sequential number like that.

We need to take a bit of time and get this one right. Over and over, in all sorts of systems this simple scheme has been seen to break down under real use. Linux package systems even allow for this simple numbering, but its use is now strongly discouraged.

The best thing is to start a wiki page listing out all the items that might be affected, and how the numbering would address it.


And, yes, I've worked professionally on creating and using document systems, XML systems, update systems and others many times where we had to address just such issues.
Jon Cruz
2010-04-06 19:09:40 UTC
Permalink
On Apr 6, 2010, at 4:52 AM, Krzysztof Kosiński wrote:

> I think being able to create multiple desktops for the same document
> is a huge misfeature. It introduces considerable additional complexity
> for little benefit. All applications I have ever used work like this:
> 1. You open a document.
> 2. The document stays in memory until you save and / or close it.
> 3. If you open the same document in a different window, those two
> copies are not connected in any way.
> 4. If you save one of them, the second window can complain that the
> file was modified, and offer to reload in such case (if the app is
> smart enough). If you don't reload, the document should be considered
> unsaved, e.g. the Save toolbar item should bring up the Save As
> dialog.

I'm not sure which programs you are most experienced with, but most that I use and the artists I've seen use do not do things that way.

It is far more common to allow for opening multiple windows on a *single* live in-memory document. Edits in one window are immediately reflected in the other. And yes, I'm speaking of actual windows here, not just split pane views.

Among the software that I know does this are GIMP, Adobe Photoshop, Adobe Illustrator and even Microsoft Word. They all do things the same way that Inkscape currently does. And there are many very strong usability and workflow reasons to allow for this.
Krzysztof Kosiński
2010-04-06 19:59:59 UTC
Permalink
W dniu 6 kwietnia 2010 21:09 użytkownik Jon Cruz <***@joncruz.org> napisał:
> It is far more common to allow for opening multiple windows on a *single* live in-memory document. Edits in one window are immediately reflected in the other. And yes, I'm speaking of actual windows here, not just split pane views.
> Among the software that I know does this are GIMP, Adobe Photoshop, Adobe Illustrator and even Microsoft Word. They all do things the same way that Inkscape currently does. And there are many very strong usability and workflow reasons to allow for this.

I am 99,9% sure it is impossible in Word, because opening the same
document for the second time simply focuses the existing window
created for that document.

The implementation in GIMP is different from "many SPDesktops for an
SPDocument". GIMP just shows the same editing controls (e.g. selection
cue) in every window - it's like creating a new NRArena. It is
definitely not like creating a second SPDesktop for the same
SPDocument - in GIMP, that would be like creating a new toolbox and an
entire new instance of GIMP that edits the same document.

GIMP and Adobe tools use a different UI paradigm than Inkscape.
Multiple views presented in a manner similar to documents make sense
there, because the toolboxes are global and not attached to any
specific window. In our UI paradigm where each desktop has its own
copy of controls, split panes in the main window or auxiliary view
dialogs are the better solution. Two top-level Inkscape windows
editing the same document would be EVIL.

W dniu 6 kwietnia 2010 21:52 użytkownik Jon Cruz <***@joncruz.org> napisał:
> You're correct in saying we can't use the Bazaar revison. Remember that we have already experienced one fundamental flaw with that... the revision number is an illusion that can change over time. So what was r9296 today might apply to a completely different state of the code next week or next month.

Trunk has the append-only flag set, so it can't happen any more. It is
no longer possible for the trunk's revision number to decrease.

Regards, Krzysztof
Jon Cruz
2010-04-06 20:12:35 UTC
Permalink
On Apr 6, 2010, at 12:59 PM, Krzysztof Kosiński wrote:

> I am 99,9% sure it is impossible in Word, because opening the same
> document for the second time simply focuses the existing window
> created for that document.

I'm 100% sure it is very possible in Word, because I was doing it earlier this morning.
Aaron Spike
2010-04-06 20:13:15 UTC
Permalink
On 4/6/2010 2:59 PM, Krzysztof Kosiński wrote:
> W dniu 6 kwietnia 2010 21:09 użytkownik Jon Cruz <***@joncruz.org> napisał:
>> It is far more common to allow for opening multiple windows on a *single* live in-memory document. Edits in one window are immediately reflected in the other. And yes, I'm speaking of actual windows here, not just split pane views.
>> Among the software that I know does this are GIMP, Adobe Photoshop, Adobe Illustrator and even Microsoft Word. They all do things the same way that Inkscape currently does. And there are many very strong usability and workflow reasons to allow for this.
>
> I am 99,9% sure it is impossible in Word, because opening the same
> document for the second time simply focuses the existing window
> created for that document.

100% possible in Word 2007. View Ribbon -> Windows -> New Window "Open a
new window containing a view of the current document." I haven't been
able to find reference to this functionality in any Microsoft provided
online documentation yet, but here is a google books result:

http://books.google.com/books?id=rMLdA_0rI70C&lpg=PA31&dq=%22new%20window%22%20microsoft%20word&pg=PA31#v=onepage&q=%22new%20window%22%20microsoft%20word&f=false

Aaron Spike
Joshua A. Andler
2010-04-06 20:38:28 UTC
Permalink
On Tue, 2010-04-06 at 15:13 -0500, Aaron Spike wrote:
> On 4/6/2010 2:59 PM, Krzysztof Kosiński wrote:
> > W dniu 6 kwietnia 2010 21:09 użytkownik Jon Cruz <***@joncruz.org> napisał:
> >> It is far more common to allow for opening multiple windows on a *single* live in-memory document. Edits in one window are immediately reflected in the other. And yes, I'm speaking of actual windows here, not just split pane views.
> >> Among the software that I know does this are GIMP, Adobe Photoshop, Adobe Illustrator and even Microsoft Word. They all do things the same way that Inkscape currently does. And there are many very strong usability and workflow reasons to allow for this.
> >
> > I am 99,9% sure it is impossible in Word, because opening the same
> > document for the second time simply focuses the existing window
> > created for that document.
>
> 100% possible in Word 2007.

Also doable in the OpenOffice.org Word Processor. "Window>New Window"
achieves it.

Cheers,
Josh
Jon Cruz
2010-04-07 03:40:32 UTC
Permalink
On Apr 6, 2010, at 1:38 PM, Joshua A. Andler wrote:

> On Tue, 2010-04-06 at 15:13 -0500, Aaron Spike wrote:
>>
>> 100% possible in Word 2007.
>
> Also doable in the OpenOffice.org Word Processor. "Window>New Window"
> achieves it.


You can add Emacs and Microsoft Visual Studio to the apps that do multiple windows live connected to the same single document.
~suv
2010-04-06 01:21:41 UTC
Permalink
On 6/4/10 02:46, Krzysztof Kosiński wrote:

> Note that this is essentially a design error in the guides and the 3D
> Box tool, and we'll have to fix it sooner or later. Probably the
> approach I've taken (convert coordinates at the DOM level) is wrong,
> and I should handle this in sp_document_create by fixing the incorrect
> values in the XML as the document is loaded. This would fix the guides
> + undo issue.

Inkscape 0.47+devel r9295:

Newly created horizontal guides don't stay where they are dropped but
immediately move to the mirrored location. Origins of vertical guides
move to the mirrored position. Diagonal guides can't be positioned as
intended either, guides converted from objects don't align with the objects.

this is a regression compared to r9290.

~suv
~suv
2010-04-06 01:57:26 UTC
Permalink
On 6/4/10 03:21, ~suv wrote:
> On 6/4/10 02:46, Krzysztof Kosiński wrote:
>
>> Note that this is essentially a design error in the guides and the 3D
>> Box tool, and we'll have to fix it sooner or later. Probably the
>> approach I've taken (convert coordinates at the DOM level) is wrong,
>> and I should handle this in sp_document_create by fixing the incorrect
>> values in the XML as the document is loaded. This would fix the guides
>> + undo issue.
>
> Inkscape 0.47+devel r9295:
>
> Newly created horizontal guides don't stay where they are dropped but
> immediately move to the mirrored location. Origins of vertical guides
> move to the mirrored position. Diagonal guides can't be positioned as
> intended either, guides converted from objects don't align with the objects.
>
> this is a regression compared to r9290.

r9295:

Rows & Columns is broken and doesn't rearrange the selected objects as
expected (checked against 0.47 and r9287)

~suv
~suv
2010-04-06 10:32:06 UTC
Permalink
On 6/4/10 03:57, ~suv wrote:
> On 6/4/10 03:21, ~suv wrote:
>> On 6/4/10 02:46, Krzysztof Kosiński wrote:
>>
>>> Note that this is essentially a design error in the guides and the 3D
>>> Box tool, and we'll have to fix it sooner or later. Probably the
>>> approach I've taken (convert coordinates at the DOM level) is wrong,
>>> and I should handle this in sp_document_create by fixing the incorrect
>>> values in the XML as the document is loaded. This would fix the guides
>>> + undo issue.
>>
>> Inkscape 0.47+devel r9295:
>>
>> Newly created horizontal guides don't stay where they are dropped but
>> immediately move to the mirrored location. Origins of vertical guides
>> move to the mirrored position. Diagonal guides can't be positioned as
>> intended either, guides converted from objects don't align with the objects.
>>
>> this is a regression compared to r9290.
>
> r9295:
>
> Rows & Columns is broken and doesn't rearrange the selected objects as
> expected (checked against 0.47 and r9287)

r9297:

The center of the initial view when opening a document appears moved: it
is relative to the new location of the origin, which - depending on the
initial zoom factor - results in rendering a completely different
(possibly empty) part of the drawing than seen with previous Inkscape
revisions before the change.

see attached example: opened in current revisions the attached document
seems empty, but it was saved zoomed to the content. This is potentially
confusing for casual users who might get the impression to have lost
their designs saved with 0.47 or earlier releases.


~suv
Continue reading on narkive:
Loading...