On Apr 3, 2010, at 10:58 AM, Krzysztof Kosiński wrote:

W dniu 3 kwietnia 2010 19:47 użytkownik Jon Cruz <jon@...18...> 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)

W dniu 3 kwietnia 2010 22:30 użytkownik Joshua A. Andler <scislac@...400...> 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

W dniu 3 kwietnia 2010 23:36 użytkownik <J.B.C.Engelen@...1578...> 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

W dniu 4 kwietnia 2010 00:12 użytkownik <J.B.C.Engelen@...1578...> 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

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

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

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

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

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

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

On Mon, Apr 5, 2010 at 8:02 PM, Jon Cruz <jon@...18...> 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

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 [bryan@...2310...] 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

W dniu 5 kwietnia 2010 22:04 użytkownik ~suv <suv-sf@...58...> 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

2010/4/6 Jon Cruz <jon@...18...>:

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-sf@...58...> 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

On 6 April 2010 13:18, Aaron Spike <aaron@...749...> wrote:

Krzysztof Kosiński wrote:

...

2010/4/6 Jon Cruz <jon@...18...>:

...

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

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-sf@...58...> 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2010/4/6 bulia byak <buliabyak@...400...>:

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.

2010/4/6 Krzysztof Kosiński <tweenk.pl@...400...>:

W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak <buliabyak@...400...> 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 :)

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.

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.

W dniu 6 kwietnia 2010 21:09 użytkownik Jon Cruz <jon@...18...> 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 <jon@...18...> 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

On 4/6/2010 2:59 PM, Krzysztof Kosiński wrote:

W dniu 6 kwietnia 2010 21:09 użytkownik Jon Cruz <jon@...18...> 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%20w...

Aaron Spike

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.

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