I don't use Sitespinner often, but whenever I do I seem to find something screwy in the first five seconds of using it.

If I create an object (a shaded square for example) and then align it (absolute) to the edges of the page, it sits next to the blue borders, which are 0,0. But, if I go into the transformations tab of the object editor and rotate it 90 degrees, and align it in the same way (using the align to page edges buttons) it's often 2 pixels or more away from the edges.

Things get even stranger if I turn off the objects border line. If I create an object and firstly disable its border line, the object will align right up against the page sides, starting from 0,0! If I then rotate the object 90 degrees, it now only aligns from 1,1.

Obviously something is seriously wrong with the inner workings of the program, and I hope that it gets fixed at some point because it's darn annoying to use right now. If you'd like images or anything else to show what I'm doing, please let me know.

I guess if you are able to turn off the object's border line you are using SS V2.70e?

Using default rectangles, I can certainly see discrepancies between workpage view and preview. [Edit: Later, I think I was mistaken here. My test project -- see below -- shows no positioning discrepancies.]

Looking at the preview code, the rectangles do actually align -- the x or y coordinates are the same. But on workpage view there appears to be a 1 to 3 pixel discrepancy when aligning left, top or bottom (but not right). So it seems like a problem with the workpage display.

A complication is that a rectangle that is 100px square gives an image file of 102x103px. The rotated rectangle is one pixel wider and higher. A one pixel border each side could add two pixels to a dimension, but beyond that I can only think of maybe something to do with the anti-alias.

I didn't see any difference with the object's border line on or off, but nonetheless I agree -- it looks like there are some bugs here.

This message has been edited. Last edited by: Bruceee,

Thanks for confirming.

quote:

...beyond that I can only think of maybe something to do with the anti-alias.

I thought that as well, but it's still an issue even if you disable it.

quote:

I guess if you are able to turn off the object's border line you are using SS V2.70e?

I thought the option to say, 'no line' has always been there... but yes, I'm using V2.70e. I believe it's a beta, but these issues have been around for a long while even so, since I've run into a few like this before. I'm actually amazed no one has noticed this kind of thing until now.

On a side note- Is it just me, or is it a little confusing in Sitespinner having the page's border start at 0,0, yet (horizontally speaking) end on the exact width of the page? For example, if I have a rectangle that's 800 in width, no matter what I do the edge of the rectangle overlaps one edge of the page border line. If a page starts at 0 and is 800 in width, wouldn't it be clearer to have the border line fall on 799 and not 800? That way you know an object that falls on both the left and right (top and bottom also) border line you're within your limits.

OK I see now, I misunderstood the 'no line'. It is actually a zero thickness outline, as done in the Quick Editor -- I took it to be something else. With that in mind, this now makes sense:

quote:

Things get even stranger if I turn off the objects border line. If I create an object and firstly disable its border line, the object will align right up against the page sides, starting from 0,0! If I then rotate the object 90 degrees, it now only aligns from 1,1.

It seems to me the borderless unrotated rectangle is the only one that starts at x=0. Other variants rotated with or without border start a little inside that. (x=1 or x=2.) This affects only the workpage -- in preview, the code shows the image objects all with a left=0.

Because SS has tendency to put a one pixel "invisible" border on some images, (I think for anti-alias) you might then think there is an offset in preview too -- there's some scope for confusion there! If you look at the left values in the code, that's where the object really is.

Re the guide borders. For an 800 design width, the left border is at 0 and the right border at 800. You should keep inside that right hand border, which gives a range of 0-799. But I agree with you about the consistency. At the left edge, you can be on top of the border but not so at the right edge. There might also be a case for using x=-1 for the left hand border -- then the same rule (inside but not on top) would also apply to both edges.

If you test with an 800 wide rectangle (as I just did), use a borderless unrotated rectangle. A one pixel border on a nominal 800 width rectangle gives an image width of 802 which wont fit.

So there are indeed some little bugs here which cause the workpage to deviate from WYSIWYG.

Once again, thanks for going over things.

I like Sitespinner... it's nice and easy to use (aside from the odd interface design aspect I've mentioned in the past) but for acurate wysiwyg work it really can do your head in! I hope these issues get dealt with quickly, so I can recommend the program to friends without having to say, "Well it's great, aside from the times when things appear in the wrong place when they aren't really."

Not a good way to sell a program, let me tell you

I see that the align buttons put a rotated object in a slightly different position that a non rotated object (which should probably not happen, as you say) but I don't see any difference between what you see in the work window and what you get in a preview. Do you have the 'High Render work window' checked?

The main thing is that what you see should be what you get (in High render mode). If you don't see that can you give specific example that I can try.

Re. the guide borders: I'm not sure I agree. The number corresponds to the actual pixel coordinate system on a web browser. That is, if you place something. in HTML, at 0,0 it will be at the leftmost edge and if you place it at 0,800 it will be where the guide border is.

Remember also that keeping something inside the 800 pixel mark doesn't mean it will be within a browser window on an 800px screen. That is because the browser has scrollbars and window borders and those can also be adjusted by the individual. So while the guidelines are guidelines you probably want to stay well within them if you want to be sure all veiwer with ab 800 px screen will not be cut off. You can always choose custom guidelines if you have a specific number in mind

quote:

Do you have the 'High Render work window' checked?

I do, yes.

quote:

I see that the align buttons put a rotated object in a slightly different position that a non rotated object...

And 'no line' makes a difference to this as well.

quote:

That is, if you place something. in HTML, at 0,0 it will be at the leftmost edge and if you place it at 0,800 it will be where the guide border is.

Fair enough then. I was looking at it more from an artistic point of view, in that, the border line should signify either the limits of the page, or border the viewable work area... such as how paint programs would work.

quote:

Remember also that keeping something inside the 800 pixel mark doesn't mean it will be within a browser window on an 800px screen.

I'm aware of this... but it's a good reminder

quote:

The main thing is that what you see should be what you get (in High render mode). If you don't see that can you give specific example that I can try.

According to Bruceee the issue is that when you use the align buttons the object is in the correct place- it just doesn't appear to be there, visually. I can confirm this.

One other small thing (not previously mentioned) is that if you draw out a guideline too 800 with the mouse down (on an 800 wide page) you'll see that it sits next to the border line. But, when I let go and place it at 800 it suddenly falls onto the border line. Visually what I'm seeing isn't what I'm getting... unless of course that was intended.

Here are some test cases and a project file. To create this, these steps should do it:

Start a fresh project -- SS V2.70e with High Render work window

Create a default rectangle

Give it a shade so you can easily see it

Copy and paste it to give four shaded rectangles in all

Obj1: leave as it is

Obj2: rotate 90 degrees (Quick Editor > Object tab)

Obj3: remove the border (Quick Editor > Outline tab)

Obj4: remove the border and rotate 90 degrees

Space the rectangles in a vertical line with the horizontal edges just touching

Use the left align button (bottom toolbar) to align each rectangle individually to the left hand margin

Hide the guide border and look at the gaps between the rectangles and the left margin.

This is what I see:
Obj1: 2px [Edit: later looking closer, really only 1px]
Obj2: 3px [Edit: really only 2px]
Obj3: 0px
Obj4: 1px

If you group the objects and then align the group, you get better results, but still not perfect.

In preview with IE7 I see the same gaps. The code gives each with left:0px, so the gaps are caused by the extra margins SS puts on the images. These are the sizes of the image files:
Obj1 102x103
Obj2 103x104
Obj3 100x101
Obj4 101x102

I have had issues with margins around SS created images previously, so if VM can get rid of them that would be great, and it may well fix these problems too.

And sorry, this is off topic, but worth pointing out I think:

The color purity in my example is not great. There are noticeable shadows inside the top and left borders of the top two rectangles. These shadows are actually built into the image files. (Preview or publish, not on the workpage.) Does this indicate another problem with the way SS is rendering these image files?
[Edit. Complete red herring. Had I used the correct image format .png instead of .jpg this would not have happened.]

Harpo,
Perhaps I can clarify about the guide margins. I take your point about staying well inside margins to allow for window "chrome". But the basic issue will arise for any guide margins, including custom ones. Consider an 800 wide page without chrome allowance:

In an 800 wide page currently, the left margin is on exactly 0px. At the right hand edge, the right margin is on exactly 800px. We knew that already

If you have an object that is exactly 800px wide, to fit it into a published 800 wide page, it has to sit on the left margin, but just inside the right margin. There is an inconsistency there caused by the first pixel being x=0. On the left margin, but inside the right margin.

Reactor's suggestion was to position the right hand margin on x=799. Then the same rule applies to both borders -- you can place objects inside or on the borders.

My suggestion was to instead position the left margin on x=-1. Then the rule would be to place objects inside the borders but never on them. Of the two, I think this is a better reflection of the real world, and would remove a little clutter from the actual work area.

Reactor,

quote:

...if you draw out a guideline too 800 with the mouse down (on an 800 wide page) you'll see that it sits next to the border line. But, when I let go and place it at 800 it suddenly falls onto the border line. Visually what I'm seeing isn't what I'm getting... unless of course that was intended.

How do you "draw out" a guideline? Are you referring to a tab stop on the ruler line? Or an object? If you drop an object near 800, and you have snap-to-grid on, it might well snap to exactly 800.

This message has been edited. Last edited by: Bruceee,

quote:

My suggestion was to instead position the left margin on x=-1. Then the rule would be to place objects inside the borders but never on them. Of the two, I think this is a better reflection of the real world, and would remove a little clutter from the actual work area.

I agree that's the option which makes the most sense, except people might get confused if the borders aren't there to see (if that option was still available in a revisted Sitespinner).

quote:

Are you referring to a tab stop on the ruler line?

Sorry, 'draw out' was the wrong term to use. Yes, I'm referring to a tab stop... or Guide Line.

Thanks for the example files Brucceee. That makes things clearer.

I see a couple of things but I am not sure about others.

- "Clicking the Align Left button ... produces ... a variation ..." "In preview, the same misalignments show."

Ok, we agree here. My point in the last post was that even though the rotated rectangles don't go to exactly the same place as the unrotated ones when you use the alignment buttons (no doubt it would be better if they did), they do go to the same place that they will appear in the preview. So in that regard what you see in the workspace is what you get in the browser.

One thing: I only see a 1px difference between the left edge (the black outline) of obj1 and that of obj2, in your example.

So... As you and reactor and you have said, the apparent positioning of rotated object, using the alignment buttons is not the same as unrotated objects.

At first look this appears to be due to the way SS is rendering a rotated rectangle rather than the way it is positioning it. We will look in to the problem.

- there is an undesirable white line showing above obj2 which does not show on the work page

This is definitely a case where what you see is not what you get. It seems to occur only when the rotated rectangle is placed directly below (touching) the rectangle above it. If you move obj2, in your example, up or down 1 pixel the problem does not occur. We will look in to that too.

- Also, the color purity is not great. There are noticeable shadows

I think this is because you have the images rendered in jpeg format (which as you know is a good choice for geometries). Let me know if that is not the reason.


-I have had issues with margins around SS created images previously, so if VM can get rid of them that would be great, and it may well fix these problems too

I recall that you considered them 'foibles' but they should not affect the end result unless there is a bug with them. Think of them as a swatch of background. When SS re-renders an image it takes underlying images into account. There may well be other ways to re-render images but currently that is the way SS does it and as I said, it should not affect the appearance on the browser page.


- My suggestion was to instead position the left margin on x=-1.

I agree that may be a sensible choice. We will have to weigh the pros and cons and look for unwanted side effects of making the change. But for now though, it is still WYSIWYG. That is, if something is on the 800px line in the workspace, it is on the 800px line in the browser. Same with the 0px line.

Reactor,
I don't see a problem with the tab guide. If I click on the ruler at say 700, then drag the resulting tab stop to 799 (this coordinate shows on the status bar at the bottom), and drop the tab at 799, it stays there for me.

While you are dragging the tab, the guide shows as a very visible dotted black line. When you drop, the guide changes to a much less visible dashed green line, which merges into the blue border guide line. But if you look below the y=600 point of the page, you should see the tab guide just inside the border guide line.

Harpo,

quote:

One thing: I only see a 1px difference between the left edge (the black outline) of obj1 and that of obj2, in your example

You're right -- now that I put my glasses on I can see it too. These are the differences I see now -- it's getting better
Obj1: 1px
Obj2: 2px
Obj3: 0px
Obj4: 1px

quote:

- Also, the color purity is not great. There are noticeable shadows

I think this is because you have the images rendered in jpeg format (which as you know is a good choice for geometries). Let me know if that is not the reason.

Right again, and I did know that too -- just completely overlooked the fact that the images are jpegs

Re the -1 margin. If (big if!) you were to implement this, I would see the horizontal ruler line moving right by one pixel. The 0px position could then show a calibration mark, and the blue guide would show at the -1px position. If you see a problem in users mousing to the -1px position, could you cut off at 0px -- as happens now if you mouse too far left?

Thank you for looking closely into these issues. I accept that there are "implications" making changes -- but at least you know what the issues are

I've put together a video to show the problem I'm having. (you'll need the techsmith codec to view it). When I drag a tab guide out to one of the border lines, you can see how even though when visually on it, it drops to be next to it, or 1 to the right. Hopefully I haven't misunderstood how it's supposed to work

http://www.ringsofrexor.com/tabbug.avi

I didn't view the video, (dialup user here, without the codec!) but I can see the problem now. You are very observant!

While you are dragging a tab stop, the guide shows as a black dotted line. This line is visible while the mouse button is down. If you position the dotted line exactly on the blue guide border, the mouse position indicator says "801". When you release the mouse button to drop the guide, the green tab guide visually seems to be correct at 801.

Similarly with the left-hand guide, when the mouse position indicator says "0" the black dotted line is just off the left of the page.

So it seems that the display of the black dotted line is one pixel to the left of where it should be.

Harpo, if you're looking at this, these seem to be other little anomalies:
1. You can drag tab stops more negative than 0 in both the x and y directions (off page) -- as reported by the mouse coordinates on the status bar.
2. Similarly, when you mouse off the ruler line in the same negative directions, the mouse co-ordinates are negative and invalid. They are lumpy -- they no longer change smoothly.

quote:

You are very observant!

Thanks

quote:

2. Similarly, when you mouse off the ruler line in the same negative directions, the mouse co-ordinates are negative and invalid. They are lumpy -- they no longer change smoothly.

...though they do when draging a tab to -100