Document Suite -> GetDocumentPageOrigin

[Toto RoToTO]

Hello,

I just want to know if the coordinates returned by with method, is in native window coordinate, or should i convert this natives screen coordinate into artwork coordinate.

Retrived values don't match artworkbrower values.

Any help will be appreciated.
Best regards,
Thomas

[A. Patterson]

I believe the coordinates returned are (like almost everything in the SDK) in points/pixels (which are the same numerically). It doesn't matter what the document is set to, the API always uses points/pixels. So I'm *assuming* you're working in centimeters or something that's not points or pixels, which would explain the discrepancy. Looking at how I use that call, I don't see any special sauce to make it work well with the rest of my code, so I'm assuming there's nothing peculiar about it. Let me know if my assumption is wrong though.

One thing you should note: if you're using the document origin, make sure you test for the case when the user changes said origin (show rulers, click in the upper-left box of the rulers & drag). That's a very common problem for anyone depending on the origin for anything (even Adobe has some trouble with this). There is a solution, but I won't post it unless you need it (or someone else asks for it) since it gets into discussions about a part of the SDK most people don't need/want to know about :)

[Toto RoToTO]

I am actually working on PatternSuite and ColorSuite.
For a kPattern, The color union c is the actual color information and references an AIPatternStyle structure.

The pattern fill is generated from the page origin rather than relative to the object. That is the reason why I have to retrieve the page origin.

Since all datas retrieved with API is in Pixel/Point, I need the origin to be in Pixel/Point.

So, if you could explain your solution, i will be nice.
Thanks,

Thomas.

[A. Patterson]

Okay, in a nutshell, you have to get the page origin and then use the AIHardSoft suite to convert to 'hard' coordinates. There are two coordinate systems at work in AI, the 'hard' & the 'soft'. The 'soft' coordinate system is the what you see displayed and can be shifted & have its units changed. The 'hard' system is static and never changes; so if you have a 'hard' coordinate you know it's rock solid.

The trick is knowing which you have; they both use AIReal so you can't tell just by looking at the type.

Now, the solution I was talking about depends on how this system affects you. In our case, I have to pull the page origin when a document opens & record it's true 'hard' coordinate. Then when I perform certain operations, I check to see if the page origin (0,0) has shifted. I can do this by converting (0, 0) to a 'hard' coordinate and comparing it to what I recorded last -- if they're different, there's been a shift. Moreover, I can tell how it's shifted. Then I just make whatever changes I have to make and then update the 'hard' coordinate for the origin with it's new location. And so on!

I don't know how a shifting page origin will affect you -- it might not at all! But this information might still be useful. With luck you won't need to handle a shifting origin, but if you're concern about the 'true' location of something, the AIHardSoft suite is what you probably want.

[btemp-27oI4u]

I am also having some problems with this that sound like they may be related to your "solution" posted above.

When my plugin runs, I get the coordinates for the page rectangle in the document.

Next, I get the ruler origin.

I then compare the two values (after converting them to the same system) to see if the origin is in the lower left of the page.

This all works under most circumstances. On some of my files however, after running the plug in, it correctly tells me the origin is NOT in the lower left. I then drag the origin to the lower left and run the plugin again. This time, it incorrectly tells me the origin is not in the lower left. Going through the debugger, I have determined that it seems like the page coordinates are not getting properly updated after an origin move.

If I draw some art and run the plugin again, the coordinates are updated and the plugin runs correctly.

Is there some way to force Illustrator to update these coordinates via the SDK? As I said, on most of my files it works correctly, the coordinates update when the origin is moved. But on a select few, they don't seem to update automatically.

[btemp-27oI4u]

So, after looking into it a little more, the problem seems to be related to crop areas updating inconsistently. If I have several crop areas in a document, the coordinates of the currently selected one is updated and the crop area remains positioned correctly. All the other crop areas coordinates don't change, so their positions "move" so they are in the same place relative to the origin. This doesn't seem like the intended behavior of crop areas when the origin moves.

[Toto RoToTO]

The problem was that I do not have all informations about different coordinate systems used at different level of illustrator. (I didn't take a look at "AIHardSoft.h".

I assumed that there was two different coordinate systems, but I did not know how to convert from one system to another.

I worked on Pattern Suite (pattern fill), and I wasn't aware that the matrix stored in an #AIPatternStyle maps coordinates from pattern space to internal artboard space, whereas the matrix for an image maps from image space to public page space. (I had doubt ;))

In my export plug-in, all PatternArt are rasterized. In order to place correctly generated RasterArt I need to retrieve transform matrix and properties such as shiftDist, shiftAngle, scale of the AIPatternStyle, and apply that to the generated RasterArt.

I did not convert AIPatternStyle' matrix to soft, and tried to apply this directly to generated RasterArt. As a result, raster was always shifted.

I will implement matrix conversion, and try this.
Thanks,

Thomas.

ps: I am not fluent in english, but I hope being clear enough.

[Toto RoToTO]

Bug fixed. I do not have export problem any more.
The problem was that datas was exprimed in the public coordinate system or in the internal artboard coordiante system.

Now that bug is fixed, all datas exported used the public coordinate system. So there is any more shift problem for rasterized Pattern Fill.

Thanks again.
Thomas.