Hi all -

I am not sure how to describe exactly, but when I try to paste images into the scratch area on the right, SMAth starts to auto paginate and prevents me from manually move the graphic over.

Here is a screenshot.



I do not remember this behavior. I am used to piling up screen snips and the like on the right as references as I work.

I wonder if one of the text plugins is kicking in, but which one? PRConn1.sm (1 MiB) downloaded 36 time(s).

Dennis

Hello.

The reason is in your third image (according to what I see on the screenshot).
The rule is: your regions should always be located in the vertical bounds of the page, even if it is a scratch area.
Because of the size of your 3-rd image SMath Studio cannot display it in the vertical page bounds (space of the first page just not enough for this). That is why SMath Studio automatically reduces available size of the first page (notice a gray area) to put this 3-rd image (and all content with larger y-coordinate) to the next page.

Solution for you is to make the image smaller.

Best regards.

Maybe we should make the background out of the bounds different where stuff can't be placed, like in the image below, so it will be easier to spot when something hits the bottom marggin in the RHS zone.

Not a problem actually. If you createing such documents often then it may be better for you to switch layout from Pages to other options.

Wrote

Maybe we should make the background out of the bounds different where stuff can't be placed, like in the image below, so it will be easier to spot when something hits the bottom marggin in the RHS zone.

I'm pretty sure it is more convenient to make it impossible to put regions outside of the page (in Pages layout).
Just look at MS Word for example. You can't do such things there. It means that this is what people expected.

Breast regards.

For me, an acceptable solution would be to still allow putting stuff outside the printing bounds and completely ignore it for formatting of the page. If I understand the topic opener right, the problem was the side effect of invisible stuff to the formatting (pagination) of the visible stuff. Users may well want to work in page mode and see stuff outside printing bounds.

Wrote

For me, an acceptable solution would be to still allow putting stuff outside the printing bounds and completely ignore it for formatting of the page.

Yes, exactly! Well said Martin.

I know it's a challenge to implement, but I think the ability to put stuff in the RHS is really important for annotations, documentation, secondary sanity checks, ideas, etc... Anything that should not be seen on printed or exported files, like what it is possible to do in excel or ppt. At least it's how usually I arrange my documents.

In practice LHS content should drive the pagination, RHS regions should bruteforce split crossing regions and continue in the next page RHS.

As side note, to improve the LHS pagination, as you suggested some time ago, being able to set a grid of break points in the regions would be nice too (but this no matter of the thread 🙂)

Wrote

In practice LHS content should drive the pagination, RHS regions should bruteforce split crossing regions and continue in the next page RHS.

From the users POV, why would you need the split of RHS stuff at pagebreaks? If something is larger than a page just let it occupy the space it needs, just like in the other display modes. It's just a display issue and never going to be printed.

Wrote

From the users POV, why would you need the split of RHS stuff at pagebreaks? If something is larger than a page just let it occupy the space it needs, just like in the other display modes. It's just a display issue and never going to be printed.

Because y-coordinates and worksheet editing. Imagine two regions in the lhs, one at the bottom of page #1 and the other at the top of page #2, let's call it initial state. If I move everything down, they will be stacked on the second page, as expected.
Now in the initial state add two comments on the RHS, same vertical size of the lhs regions, move everything down to the second page, everything works.
Let's say the comment of the first region has a bigger height that fits in the dark gray zone of my picture above; in the initial state there isn't problem, but if you move down the regions to the second page, the second comment will be hidden by the first. For the same reason you cannot create regions in that space (this zone in the end is the dashed line between the pages in printing bounds view, an imaginary range of coordinates between the bottom edge of the first page/region and the top edge of the second page/region, where should they be moved respect to the others when vertical space is added or removed above them?).
In the end having stuff drawn in that area and then editing the worksheet what you'll experience on the RHS vertical spaces appearing or overlaps, and that zone where regions cannot have origin but has no clear gui; that's why my suggestion to grey out that zone.
One might want the rhs like a continuous blackboard, but in that case the cost is to lose the RHS/LHS vertical link; it's ok on a locked LHS layout, but once you start moving things around, becomes a problem.

Wrote

Wrote

In practice LHS content should drive the pagination, RHS regions should bruteforce split crossing regions and continue in the next page RHS.

From the users POV, why would you need the split of RHS stuff at pagebreaks? If something is larger than a page just let it occupy the space it needs, just like in the other display modes. It's just a display issue and never going to be printed.

It sounds very logical for me too. The real problem of this solution is on technical side: we have a single Y axis for all Regions on the Worksheet and Pages splits this Y axis during the whole Worksheet. This means that there is no logical Y axis in the spaces between Pages working bounds at all. It's like a Black Hole - it is not clear how to manage stuff (Regions) into this Hole (space), at least with a rules of our universe...

So we can handle such situations like I've implemented several years ago (current solution) or we can cut content in RHS as Davide suggested (it is a bit harder, but possible).

Wrote

As side note, to improve the LHS pagination, as you suggested some time ago, being able to set a grid of break points in the regions would be nice too (but this no matter of the thread 🙂)

I've tried to implement this several times, but failed. This is the only reason why we still do not have new very desirable document mode - something like SMath Word
But I'm on this way and will do this sooner or later! Everything else is already available: pages mode, regions inside regions etc.

Best regards.

I know, thank you for every attempt

Wrote

something like SMath Word

not crazy! This brings back nightmares of TEDDS from the LAST century!

If Pages view and Printing bounds view used the same regions, would have the same results?

I am not sure if this is the same issue, but when I try to resolve a bounds conflict, the highlight region is still in effect and then SMATH moves things in a way that I do not understand. It clashes with things on the previous page.





Any ideas?

Wrote

I am not sure if this is the same issue, but when I try to resolve a bounds conflict, the highlight region is still in effect and then SMATH moves things in a way that I do not understand. It clashes with things on the previous page.

Any ideas?

Hello.

It is really hard to understand what is going on here, but I would suggest you to select a region you are talking about and try to move it up/down using keyboard arrow keys. This will help you to understand the logic under the hood.

Please note: we are still have a positioning issue when moving regions with a mouse in Page mode (if you will move a region by mouse from one page to another), so something it is easier to use keyboard.

Best regards.

Wrote

Wrote

something like SMath Word

not crazy! This brings back nightmares of TEDDS from the LAST century!

If Pages view and Printing bounds view used the same regions, would have the same results?

It is too late today so I'm afraid if I understood a comment incorrect again, but if it is a reaction to what I said regarding mode when SMath Worksheet will look like MS Word document, then I can say that this mode will not be available in SMath Studio itself, most likely it will be another application with another name, so nothing bad will happen with layout you currently have in your files.

...while Pages view and Printing bounds view are 100% back-compatible. The difference is just how pages are splitted on screen and printer. You can always switch a view without any drawbacks (it is just a flag for the renderer).

Smath auto-paginates the Page Setup [Portrait, Landscape, Custom]
To free a region for inserting objects [math region(s), image ...]
put the cursor + where to start free space, keep pressing Enter.
That's what you didn't do from your snippet.