Currently when you insert lines/vertical space, it will
push lower lines off of the viewable page area. It
would be nice to have an option to push those lines
onto the next page/successive pages. ~Loki
That would indeed be nice, but it's not so easy to
implement, and there are delicate design decisions:
- what should happen to the text that's already on the
following pages? (how far does one propagate everything...)
- there's no concept of "lines", just individual strokes,
and so there's no guarantee that one would be pushing an
entire line of text rather than just a single word, or
worse, a letter or a part of a letter...
- when removing vertical space, should things be brought
back ? (and how ?)
Something easier to implement, less powerful but less risky
in terms of user interface choices, would be the following
behavior:
- in the default version of the tool, if the bar is pushed
below the bottom of the page, then a new page is created,
containing all the text that has been pushed.
- upon turning on some option, this mechanism is disabled,
and instead, the page height is automatically increased as
needed so that text never becomes invisible.
I'll think more about it, but let me know if you have
thoughts about this.
Denis.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Release 0.2.2 improves on the previous behavior (although
it's still not ideal). The vertical space tool can move
items to the next page, but only when the entire block being
moved has crossed the page boundary; items on the new page
are not moved. Concretely, this means you can proceed as
follows: first, use the vertical space tool to insert space
where you want (say on pg.1). Second, on the next page
(pg.2), use the vertical space tool to create space for
anything that you will be pushing off from the first page
(or insert a new blank page after pg.1 if that's where you'd
like the pushed off text to go). Third, use the vertical
space tool at the very bottom of pg.1 to move all the
invisible stuff to the top of pg.2.
I'm still hoping to come up with something smarter in a next
release, but I believe this is acceptable as a temporary
fix, and this now becomes low priority, at least until I
have figured out what the right behavior should be.
Denis.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know how easy this would be to implement, but one
easy way to solve this is to have an option for a continuous
page. You could add more space as if you were adding
another page, etc, but it would just add length to the
current page. It would be useless if you needed to print
it, but great for note-taking ;-)
Alternatively, and this is more complicated, develop a
function/routine to have the program "guess" where the lines
are. The actual line height is a given, and if I understand
things correctly all strokes are kept track of, so you
should be able to "guess" where the lines are. Have it
start with the actual blue lines on the page, and if, say,
90% (or whatever a reasonable tolerance level is) of the
strokes on the page begin inside those lines, then accept
them and treat each set of strokes as a "block" of text. If
not, move the "lines" a little and try again. If you adjust
a whole line's height and have not found an acceptable place
for the lines to be, adjust the tolerance and try again.
For drawings/diagrams this can also break them up by where
the strokes begin, as people will probably want to insert
enough space to move the whole drawing/diagram to the next
page anyhow. Again, I don't know how hard this would be or
how well I understand the inner workings of the program.
Keep up the great work! ~Loki
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1482965
That would indeed be nice, but it's not so easy to
implement, and there are delicate design decisions:
- what should happen to the text that's already on the
following pages? (how far does one propagate everything...)
- there's no concept of "lines", just individual strokes,
and so there's no guarantee that one would be pushing an
entire line of text rather than just a single word, or
worse, a letter or a part of a letter...
- when removing vertical space, should things be brought
back ? (and how ?)
Something easier to implement, less powerful but less risky
in terms of user interface choices, would be the following
behavior:
- in the default version of the tool, if the bar is pushed
below the bottom of the page, then a new page is created,
containing all the text that has been pushed.
- upon turning on some option, this mechanism is disabled,
and instead, the page height is automatically increased as
needed so that text never becomes invisible.
I'll think more about it, but let me know if you have
thoughts about this.
Denis.
Logged In: YES
user_id=1482965
Release 0.2.2 improves on the previous behavior (although
it's still not ideal). The vertical space tool can move
items to the next page, but only when the entire block being
moved has crossed the page boundary; items on the new page
are not moved. Concretely, this means you can proceed as
follows: first, use the vertical space tool to insert space
where you want (say on pg.1). Second, on the next page
(pg.2), use the vertical space tool to create space for
anything that you will be pushing off from the first page
(or insert a new blank page after pg.1 if that's where you'd
like the pushed off text to go). Third, use the vertical
space tool at the very bottom of pg.1 to move all the
invisible stuff to the top of pg.2.
I'm still hoping to come up with something smarter in a next
release, but I believe this is acceptable as a temporary
fix, and this now becomes low priority, at least until I
have figured out what the right behavior should be.
Denis.
Logged In: YES
user_id=1504861
I don't know how easy this would be to implement, but one
easy way to solve this is to have an option for a continuous
page. You could add more space as if you were adding
another page, etc, but it would just add length to the
current page. It would be useless if you needed to print
it, but great for note-taking ;-)
Alternatively, and this is more complicated, develop a
function/routine to have the program "guess" where the lines
are. The actual line height is a given, and if I understand
things correctly all strokes are kept track of, so you
should be able to "guess" where the lines are. Have it
start with the actual blue lines on the page, and if, say,
90% (or whatever a reasonable tolerance level is) of the
strokes on the page begin inside those lines, then accept
them and treat each set of strokes as a "block" of text. If
not, move the "lines" a little and try again. If you adjust
a whole line's height and have not found an acceptable place
for the lines to be, adjust the tolerance and try again.
For drawings/diagrams this can also break them up by where
the strokes begin, as people will probably want to insert
enough space to move the whole drawing/diagram to the next
page anyhow. Again, I don't know how hard this would be or
how well I understand the inner workings of the program.
Keep up the great work! ~Loki