Issue 43146

I think that remembering the cursor position is a *very* *useful* feature. The
point is not that it is impossible to get by without that feature. If that was
the standard, then we'd have almost no features. Most features we add are added
because they *help* and are *useful*.

Thanks to the OOoAuthors project, I regularly work with documentation, and I
find this feature very useful. It allows me to go back to a document and
continue where I left off.

What am I supposed to do now?
Write some kind of text that says "((daniel -- continue here))" ?

Don't you see some problems with that approach? For one, it's an ugly kludge for
something that used to be simple. Second, it's adding text and altering the
pagination of a document for no good reason.

Is it possible to do? Yes, this isn't the end of the world. But that's not the
point. The point is that it's a useful feature.

Cheers,
Daniel Carrera.
OpenOffice.org volunteer.

Here's a suggestion:

Can this feature be made into a setting? You can have it default to "off", but
at least allow people to set it back to "on" at some point.

Please?

Cheers,
Daniel

I'll just copy my comment from issue 39486:

Don't keep it. Revert the "feature" to the old behaviour. The user-scenario
itself is a "joke".

If Mary doesn't like the restored view, why doesn't she simply turn off "restore
editing view"?

Does Mary really add her writing to the top of the document? I doubt so. She
will add her text somewhere in the middle or at the bottom, but only in rare
cases at the top.

If you think the behaviour has to be changed, then add the option "restore
cursor position" and turn it off by default so that it can be turned on at least.

Why do you impose annoying actions on the user (pressing the non-yet-existing
shortcut?) 
There is already a shortcut to jump to the start of doc <ctrl>+<home> - why not
have Mary press use the shortcut?

You really should have listened to UFI :-(

In response to Daniel's second comment, I would like to again point out that his
suggestion is the old behavior.

this really is a useful feature that i got used to - but it felt so natural that 
it was irritating to work with 1.9 builds.

one of arguments to remove this setting - reduce options in gui. the problem is, 
as a result a feature is lost. it was functional, many people used it.

this should be brought back to 2.0 (the sooner, the better - so that no 
fundamental changes are made that make it harder to reimplement)

MRU->ES: you are named as QA-rep. in the spec. Please clarify with MMP, what to
do with this.

it's a duplicate of issue 39486.


*** This issue has been marked as a duplicate of 39486 ***

closed

um. duplicate ? again ?
maybe my english is _that_ bad ?
i believe this not a duplicate, because issue 39486 deals with a manual key 
sequence (which is a new feature), this one - with a feature that was available 
before but for some reason has been removed completely.

i believe also that ongoing discussions in issues and mailing should have 
cleared the confusion about this functionality.

could this be reconsidered, please ?

I believe this is all the same. It's about the whole design of this feature:
- should it come back as it was?
- as a check box in the options?
- what should be the default?
- should there be a shortcut?
- what should the shortcut do by default (restore view/top of doc)?

Thus it's a duplicate.
Else, it's better to concentrate the action on 1 task, but IZ is not the right
place anyway to discuss features (discuss or users mailing lists)

NO!!! This is NOT a duplicate of 39486!

Specifically, 39486 is this (the summary) "Implement a shortcut to jump to the
saved cursor position." This not what this issue is.

In this issue, I am asking for the old behavior back, so that when I open the
document it just starts were I left off. Read the conversation on that issue and
the conversation in #41136 and you will see.

I do NOT want just a shortcut, I want the 1.1.x behavior back.

Reassigned

@es comment #2 --

It is not one big issue. How many times have we been told, one issue per issue,
not to try to lump the whole thing together. This is the difference, if you read
the spec (in the url I provided) it says that v2 the only option is the doc to
open at the top and that there will be a shortcut key to restore the last cursor
position.

In the snapshots, you can only open a doc at the top (as expected), but there is
not shortcut key in the snapshots, hence #39486 is a DEFECT. Something that is
supposed to be happening isn't. If we bundle everything into that one issue (the
fact the we want the behavior reverted) and it is fixed, then the whole rest of
the conversation is lost. That is why you file two issues when you have two issues.

This issue, 43146, is a request for enhancement. We want a different feature we
want the program changed. This feature could be marked as won't fix. So, if we
lumped it with 39486 and it got marked won't fix, then the shortcut also
wouldn't be added.

Do you see the difference?

*** Issue 43993 has been marked as a duplicate of this issue. ***

I agree dcarrera: A setting for this behaviour would be the best solution.

Especially when editing big documents (I plan to write my diploma thesis with
OOo Writer) I really would like that Writer opens at that position where I have
worked  at last!

Please check if such an option could be targeted to OOo 2.01.

I'm really annoyed of having lost this feature!

Some of you may think this is not a big issue. But you must see this from the
user's point of view
Users save the document. And later they open it again to continue editing the
document...

So please implement an option to allow users to enable old behaviour...

(Maybe an interesiting alternative would be to keep old behaviour and adding an
option when saving to not store the cursor position...)

(forget my last comment. this could be achieved by setting the cursor at the
document's beginning before saving :-) )

I had the same problem (not saving cursor position) with OOo 1.0 and helped 
myself by painting red the last written word. So I could find it easier after 
re-opening the document and scrolling down. 
In OOo 1.1.2 the cursor position was saved and I was able to finish my 
dissertation (about 100 pages) without searching for the last position (because 
of lots of images and few memory scolling through the document took about 5 
minutes!). 
If the new standard behaviour will not be changed back, I'll keep on using OOo 
1.1.2 (or 1.1.4/5 perhaps) because this feature is essential for larger 
documents! I think there are more people using WRITER than IMPRESS or BASE, so 
the great advantages of OOo 2.0 could be drawn back by this. (and other things 
like the quickstart-"enhancement" #30853)

*** Issue 44993 has been marked as a duplicate of this issue. ***

Would very much like to retain the option where the cursor moves to the 
location of the last edit when a file is opened. Like 1.1.0.

For me, this would give OOO a significant edge over MS-Word.

SBA: The old behavior "vanished" on purpose. See issue 20333 for details.

In my opinion, this is about "Editors vs. readers (of Writer documents)":
(1) The EDITOR prefers to keep on writing in the last position
(2) The READER prefers to read a document from the start.

I believe that "The BIG average" use of a Writer document is "More often read
than edited". Thus it makes sense to have a "reader friendly" default.
Reassigned to MMP.

Glad to hear the functionality is being reconsidered. The default can be start 
at beginning. But useful to have an option to change it. There seem to be some 
users who feel passionate about this :-)

I don't know anyone who uses MS-Word or OOO-Writer _primarily_ for reading 
docs. Email, html or pdf is the more usual method for reading, in my 
experience :-) 

sba, it makes sense to change the default if majority of users would prefer 
other choice than current default setting. in this case a feature has been 
completely removed, so (supposedly) minority that preferred old behaviour tries 
to make some noise and get it back in oo.org :)

I agree with othr. In my experience OO.o is used for editing and
presentation/reading is done via exported PDFs. This might be different in big
companies, but why would I pass a document to s.o. which they can change if it's
not for editing? I simply do not get it.

If I as editor decide that my document should be read from the beginning (for
example because I offer a basic Calc-Sheet for download on the internet), than I
 should have an extra option to set the "start reading from beginning" flag (in
my opinion the best place would be in the file properties-dialogue).

But I guess in 99 per cent of all cases the opener of a document is just
continuing to edit a document of his own.

*** Issue 48871 has been marked as a duplicate of this issue. ***

*** Issue 48430 has been marked as a duplicate of this issue. ***

pls. bring back this functionallity, that is of so much use for me in 1.1.x, back

Stricking Ctrl-Home for someone needing to 'find' the start of a document, is
much and much faster than looking for position 'x'
So people using OOo as a powerfull editor etc, as I also do, will (in general of
course) sure be pleased with the 1.1.x behaviour.

Thank you very much!

pls. bring this functionallity, that is of so much use for me in 1.1.x, back

Stricking Ctrl-Home for someone needing to 'find' the start of a document, is
much and much faster than looking for position 'x'
So people using OOo as a powerfull editor etc, as I also do, will (in general of
course) sure be pleased with the 1.1.x behaviour.

Thank you very much!

To my opinion the bias towards the reader, vs. the writer, is wrong. Indeed,
chances are that there are a lot more readers than wirters of a document. But,
mostly, readers will read the document only once on the screen, and from my
experience readers tend to print the document rather than read it on the screen
at all, especially with larger documents - for which the whole issue is the most
important. Writers and editors, however, handle the document many, many more
times. So the disadvantage for writer/editor of the cursor not being positioned
on the last position is much greater than the disadvantage for the reader to
have to jump to the top of the doc.

So, my votes are for the old behaviour.

Cheers, jehojakim

I would like to keep the possability to get to the latest position/mutation by
opening a document in OOo writer. The reason is that I usely write very long
documents that I mostely work on for months. Therefor it is for me essential to
keep that possability also in OpenOffice.org 2 and further. I would appreciate
it iw you would put this function in OpenOffice.org 2 and further. Thank you.

With kind regards,
Philip Pasveer

retarget to OOo 2.0.1
duplicate to i33307

*** This issue has been marked as a duplicate of 33307 ***

closed; to be followed up in i33307

hmmm... 33307 is about a new shortcut... Better than nothing, but not quite 
the same as this issue which is about something more closely resembling a 
former functionality. 

I note that we already have a shortcut to return to the beginning of the 
document :-)

Perhaps I should ask: If you are going to store the last-save position (ie 
even with 33307), what is the problem with having an option to do this 
automatically? Is it a big memory or architecture problem?

erm. we already had this issue closed as duplicate to issue about a shortcut 
(and this is not about a shortcut).

i don't think it's worth to reiterate, comments to this issue since Mon Feb 21 
08:11:23 -0700 2005 reflect opinions well enough.

it seems that this issue will get burried beneath issues about adding some 
shortcut, not resolved the way users want it - by getting back the removed 
functionality.

f this is not the case, i would appreciate more verbal comments why this is 
considered a dupe and closed - and what is the current view regarding position 
restoring.

The best solution would be
a) optimal view with no shortcuts for reader (someone who opens a document for
the first time) and author (someome who has opened and edited the document quite
recently.)
b) no shortcuts
c) no additional option

Point a) is the hard part -- to detect the context under what a document is
opened. As long as we don't have a feasable solution for this I recommend to
treat the readers more politeley than the authors.  Point b) is the price that
authors have to pay for that. Point c) imposes a solution for power-users that
is totally out of sight for the average.

If I understand the specs-doc correct, the point is:
- avarage user is confused about starting in the middle of a doc;
- power-user has no problem using Shft-F5 to return to latest cursor position.
I can happily live with that.

Furthermore the specs-doc says something about an option to make default
restorage of cursor position (& view) posible. But I couldn't get the clue on
whats proposed to do with that idea.

The option "Editing view" in OOo1.1x (Tools>Options>OpenOffice.org>View) was an
all or nothing option. All modules open the document on the first page or all
modules open the documents on the last edited page. This was not good. Section
6.6. says that this options should be removed. 
I suppose this has to wait until OOoLater. Until then this option has no effect
on Writer and Impress. But still on Calc.

and what's wrong with
- option to choose wether automatically restore editing position;
- shortcut key for those who want restoring only ocasionally.

in this scenario everybody is happy - this option would be turned off by default 
and only those who want this functionality would enable it.

it's been argued in this issue a lot that most people don't read long documents 
onscreen, they print them out; usually creating/editing the document requires 
more work and iterations of opening/closing than just reading it; that there 
already is a shortcut to go to the beginning of the document (and most people 
already know what ctrl+home would do).

it feels like these arguments are just ignored without even an attempt to 
disprove them.

i feel so disappointed that i would have tried to see into this myself already - 
if only i'd knew how to code. as i do not, i can only try to reasonably justify 
my view. and i really believe that oo.org will lose by removing this 
functionality.

This might work as an interims solution. But from my point of view it is too
much effort for 2.0.1.
We have to treat different modules differently, and sometimes an author becomes
a reader and vice versa. A general option does not address this issue.

I like to see a shortcut as specified for 2.01 and hopefully an elaborate
feature for OOo 3.

set parent

As far as I'm aware, not mentioned before, is the great advantage for using
templates, when the cursor is at the past position on opening a document.

Imagine: you save the template with the cursor is on the position where the user
has to start with typing .. the cursor is just there when a new doc is created
from that template. That ís handy! 

Can this be achieved in/with 33307??

As far as I expect: yes. But I doupt that all template users know the shortcut
to jump to the saved position. So we have a bad solution for your scenario.

Do you know actual users/companies who rely on this behavior?

Long time ago, when I worked on automating corporate styles in MsO, we had a
bookmark and a piece of code to start at the start position ;-)

Not difficult to implement in OOo, however for the few projects we did until
now, there just was no need to do it, because of the default behaviour.

Furthermore, that only works when combining templates and macro code. 
For many relative easy works, where no macro´s are used, it's just fine when the
cursor is there.

"This might work as an interims solution. ... A general option does not address 
this issue."

i would like to restore editing position in all kinds of documents. actually, 
the fuss is not about adding the option, it's about removing of functional 
option and not providing that envisioned improvement where office suite would 
find out wether person wants to read the document or write at the last position.

why not leave this option until optimal solution is developed ? i don't want to 
go into bad analogies land, but it's like removing a handbrake because sometimes 
people can use it while driving and that migh cause undesirable effects.

software should help users in their work. usually i have to work with several 
documents. it is very handy if i have the latest text just after opening the 
document, it helps me to restore my ideas and get on with the work itself. 
sometimes i even don't remember that i have left a sentence in the middle of the 
document unfinished - and only when i have it in front of my when opening i 
remember that there is something unfinished.

so, shortcut key is not sufficient for my workflow, where i depend on software 
to remind me where i left my work. and why not ? this way i can concentrate on 
other things immediately instead of trying to remember which was the sentence 
that was unfinished in this 200 page document.

now there is no replacement for this feature. removing functionality and hoping 
that something a lot better will be implemented usually results in no 
improvement or it comes after several years. if there is a need to restructure 
this feature, shouldn't it be done so that it does not disrupt existing 
workflows ? in that case improvements would be warmly greeted.

It's senseful to reduce the amount of Issues by marking them as duplicates and
closing them.

But in this case you do know the difference between this issue and issue 33307:
We want to keep the opening behaviour of OOo 1.x  (the checkbox may be checked
off as standard), a shortcut would be a workaround - if it would work by now!

So it is *not* a duplicate. If you would have closed it with the real reason,
there would be much less complaint (probably we would have to open a new issue
as "feature request"). 

In my eyes the real reason is something like that (it's just a suggestion, but
I'ld like to know if I did understand you):

1) There have been complaints about the old opening behaviour by readers of
writer-documents (ACK)
2) Turning off the checkbox as standard solution disables the feature in calc-,
impress- and base-documents as well. The reader of the writer-document wants to
open the other document types where he has left them. (Otherwise he wouldn't
have a problem with unchecking the option - I think, he would open the other
documents at the beginning without many complaints)
3) People writing longer documents know better than the "readers" how to move to
the point where they want to start. So it's more senseful to ask them to use a
shortcut than the others. (ACK)
4) The implementation of the shortcut has been too complex to include in 2.0
(refer to #33307), but the "readers" must have their optimal behaviour (starting
writer documents at the start, others at other positions) in 2.0. (Do you worry
about loosing new users?  - the power-users wouldn't go to MSO anyway!)

Closing the issue with these reasons could be understood (without agreeing to),
but closing as duplicate is wrong IMHO.

Just two more points to discuss:

1) The point of starting template-based documents is a new one. Here "simple"
standard-user could have an advantage of the old behaviour, but by now we don't
know how often it is used.

2) While it is clear, that the shortcut can't be implemented in 2.0 final, it
should be the better compromise to go back to the old behaviour with turning off
the checkbox as standard. I assume that the "simple" standard-reader doesn't
mention the problem that calc-, impress- and base-documents (if he uses them at
all) open at the beginning.
For all the people using writer with longer documents there must be a
possibility to begin where they stopped at the last session (without bookmarking
every time before saving...)

I don't see why the standard-reader can't open all documents at the beginning -
or decide to open all (including writer) at the last edited position and check
the option. Who is able to check an option is able to uncheck it as well (or use
an *existing* shortcut for temporary movement to the beginning).

Perhaps there is a reason I don't have in mind - please let me know!

Bernhard

Hi gang!
so many good arguments - I'd like to tune in and sing the song of the good old
times. Cut. A general option for "advanced users" is not sufficient - IMO. Every
user is reader and of received documents and editor of her own. Roles of reading
and editing change and we cannot distinguish between the situations. 
Currently the spec defines a new behavior that was implemented partly due to
engineering constraints. The last view position is saved in OOo2. OOo2.0.1 will
add the shortcut to jump to that position.  i33307 is the task to implement this
postponed aspect of the spec.
To open the first page for Writer & Impress plus a shortcut is a better solution
for the majority of use cases. 

The behavior in OOo 1.1x was half right and half wrong. With the option "Restore
Editing views" it was half wrong and half right. If this task i43146 is about to
get the 1.1 bahavior back then you do not have my support. 

I propose to continue as specified and to develop ideas how we can better
support the editing use case for OOo3. I cannot describe it better than richlv
did. Software should support the work of the user. I, as user experience
engineer, have to consider all styles of working with OOo. And that includes
authors and users sharing documents.  In this case I fight a little bit more for
the readers.

Suggestion:
i43146 is no longer a dup of i33307
Target would be OOoLater
We discuss what this task is about. 

Hi mmp, *

you wrote:
> Suggestion:
> i43146 is no longer a dup of i33307
> Target would be OOoLater
> We discuss what this task is about. 

For me, thats all ok. But what would you think of re-opening? ;-)

To your arguments: 

There is nobody longing for the "good old times"!
The point was to disable the feature *before* we have a sufficient workaround.
Not having a possibility at all is IMHO the reason why so many people voted for
this issue, a shortcut is not the same - but it's better than nothing.
As a temporary solution I can agree to the shortcut, in the long term there
should be a document-dependent behaviour:

a) standard: doc is opened at the first page

b) if the user wants to restart at the last position he has to to two things:
   - mark a specific option (when *I* reopen this doc, it shall start at last
position)
   - make sure that the user data is used for the document properties
   the program has to save a new option in the properties to find out, if the
current user ha marked the re-opening option.

c) if the user wants the doc to open at a special position every time it is
opened by any user, it shold have an option "reopen at bookmark" (should be
usable for templates as well)

It's just an idea - not finally thought through, but perhaps a starting point.

Cheers,
Bernhard

cornouws touched on another example of why the current (1.1) functionality is
important.

At OOoAuthors we have a template for the user guide. The first page is taken up
by the chapter cover. The second contains the license information,
acknowledgements, etc. So we have to put the instructions on the third page.
These instructions tell the contributor what to do before starting the chapter.
The volunteer has to edit some fields, and must be aware of some OOo bugs and
work around them. We also provide basic writing information and links.

We save the file so that the first thing you see is the instructions. This
simple choice has decreased confusion among volunteers to almost zero.

I honestly think that the old behaviour was better. And that the proposed
"solutions" are worse than what this issue says.

Daniel.

reopen issue.

A few comments:
> To open the first page for Writer & Impress plus a shortcut is a better solution
> for the majority of use cases. 

I strongly disagree. You write that everyonw is both reader and editor. True.
But the majority of the users are editors more often than readers. And for the
readers-case there is already an easy shortcut: <ctrl>+<home>. In the unlikely
case that the users is mainly a reader, there's the option [ ] restire editing
view. The all-or-nothing approach is not wrong for the reader. If he doesn't
want the cursor-posistion, he doesn't want the zoom-level and other related things.

> If this task i43146 is about to get the 1.1 bahavior back then you do not have
> my support.

The change you did doesn't have the support of many users. A dilemma. But be
assured: This one is not about the old behavioiur, it is about having the
possibility to open documents with remembered cursor-posistion by default.

Whether you introduce another option [x] always restore editing position or do
it differently is of no interest.

In any case: This one is not a duplicate. If you insist on your new design, then
close this one as wontfix (and p*** of lot of users)...

The "optimal" solution would be:
* OOo is able to read the user's mind and act accordingly. This is not possible.

It is far easier to have the readers either uncheck the existing option or have
them press a shortcut than doing it the other way round.

> I cannot describe it better than richlv did.

Well, richlv want OOo to jump to the saved cursor position on load.

"... Software should support the work of the user. I, as user experience
engineer, have to consider all styles of working with OOo. And that includes
authors and users sharing documents. ..." 

I think, mmp is wrong with his opinion about the "old" feature. It is extremely
helpful for authors. 

Writer is a "word processor" (text processor) to write (long) text documents,
not to read them. Normal users read texts when they are printed (or exported to
pdf). It is a good behaviour, not to distribute documents, which can contain
macros or other active content. 

"Software should support the work of the user" and absolutely most work with
writer is to write documents! And this is best done with the old feature! 

I work with Writer, FrameMaker and Word and I prefer Writer because of this
"old" feature, which the other software does not have. 

Please restore it! 

Another consideration: what happens when someone doesn't know the shortcuts?

You can't expect everyone to know the shortcuts, or even most people. Shortcuts
are inherently hard to remember, and even harder to find out (how do you expect
someone to learn about the Shift+F5 shortcut, or even Ctrl+Home?).

If you don't know shortcuts, going to the beginning of the document is really
easy. Just grab the scroll bar and move it all the way up. On the other hand,
what if you want to work where you left off? For even a short 10-page document
it can be very frustrating. For a larger document, or a document where you're
not even sure if you were editing that document or not.

So, changing the behaviour in a way that makes life very difficult for the
editor and only marginally better for the reader seems like very bad usability
design to me.

Add to that, the fact that the editor spends more time on the document tan the
reader. And when the editor is finished, and wants to send the document to the
readers, he can just go to the first page and re-save. That's what I currently
do with OOo 1.1.

Cheers,
Daniel.

Furthermore: if I do send a document to others in an editable form, and do not
convert it to PrivateOpenXML (.doc), I can be so wise to place the cursor in
top, before saving.

I filed this issue a while ago, and it is so clear to me that I don't understand
some people opposition to it.

Question to mmp: Who is disadvantaged by the 1.1.x behavior?

The scenario provided (in the spec) is laughable. I have already elaborated on
this, so I won't repeat myself.

I am big fan of the arguments along the lines of OOo is not a format intended
for reading documents. Writer is text editor. There a readers for documents out
there. PDF is a good format, ebooks I guess work, but Writer is not really
intended for reading, it is for editing.

I think Daniel's point is also very good. Going to the top of a document sans
shortcut is SUBSTANTIALLY easier than finding where you left off.

I am not a big fan of the idea of making the feature document dependent. I think
it is interesting, but I don't want to have to remember everytime I make a
document to check the box. I suppose if I could edit my default template to have
that box checked, I would survive. :)

Mostly, I would like to have someone give me a real circumstance where the 1.1.x
behavior is harmful to productivity. I can give (and others have given you)
several examples of where the 2.0 behavior, even with a shortcut, hurts
productivity.

The only way I would say we could improve upon 1.1.x is to clarify the checkbox?

I mean, why is this feature okay for Calc and not Writer?

Sorry, I am rambling, but it is just so clear to me that this is a good feature,
something that propels OOo over MSO and a feature that will require me to keep a
copy of 1.1.4 on my computer for my editing work until 2.0 has an acceptable
feature.

Hi gang,
here's what I propose for OOo 2.01
a)
We will implement the shortcut Shift-F5 as specified. (i33307)

b)
IF author of the Writer document and current user of OOo (Options>OOo>User
Data>FirstName+LastName) are the same THEN open the document at the recently
used position.
IF EITHER author of the Writer document is not set OR the current user data is
not set THEN open the document at the first page.
Shift-F5 can be used anyway.

Please let me know what you think.
Matthias

Hi Matthias,

Sounds good to me.
A handy and natural distinction between user and reader.

And uhh, is there any possibility that our life in between 2.0 & 2.01 is made
easy as well :S  At least with Shift-F5?

sounds reasonable, though maybe we should compare also 'modified' field with 
current user information ?

for example, if i receive a file to work on, resave it, i would like to remember 
position for it (as i have become an editor now), but the only place my 
information is (as far as i can see) - in 'modified' field.

Hello Matthias,

I like the idea, it's a clever solution. Though I like richlv's suggestion even
better. It seems to do something closer to what you intended.

But in any event, if you use the Author field as you suggested I'll be very
happy. If you use the last-modified field as richlv suggested I'll be happier yet.

Thanks!

Cheeers,
Daniel.

I think that is a fair compromise.

I would still like to see the option implemented in the future to go back to the
world of 1.1.x. Should we open a new issue for 3.0 once this one is resolved?

Author field and last modified fields are good ideas, I think, plus shift F5 
(same as MS-Word). This would keep me happy.

Matthias, that sounds like a nice idea.
I'm still thinking how that fits to other use cases where the "old" feature came
in handy:

(1) Creating documents from a template where editing in the new document always
should start at the same position. 

(2) A workflow where a document is passed between users that consecutively add
their contributions.

Of course the shortcut would at least enable them to do so but it still looks a
bit tedious to me.

I'm still wondering wether we should work on the document side.
Documents can leave the application in different ways: they can be sent out by
email, they can be saved or copied. 

At least the first use case can easily be handled by not providing restore
information at all when we create the copy that is sent by email (we always
create a copy for various reasons), but we can also provide additional meta data
that tells OOo not to use existing information.

The workflows I described wouldn't profit from Matthias' suggestion, but we
could enable them by providing a document setting (not a global one as in
OOo1.x) that tells OOo "always restore cursor position automatically", at least
if the document is not opened read-only.

I admit that this is not thought to the end, but I wanted to point out that
there still could be room for improvement.

Hello Matthias, *

comparing author and users data is a good idea, but as richlv 
suggested "modified" should be taken into account. In my eyes the author and 
all editors (listed in "modified") should be compared to the users data to move 
the cursor to the last saved position.

If a former editor wants to start at the beginning, he does know the shortcut 
<CTRL><HOME> - in the most cases the automatism would work quite well.

Just one thing to mention: If I'm not wrong, the standard behavior is to 
set "document modified" status when a doc is printed (Options - OOo - General). 
I have the checkbox unchecked, but I think I dit it manually a lot of time ago.
Perhaps this should be standard - just to avoid confusing Mary.

For mba's reflections there should be a solution (at least in a later version).
His first point (opening template based documents) seems to be quite important 
for some users.

After you (mmp) asked for users of that feature I posted the question on the 
german users-list and got answers from people using it in everydays work: 
One told about templates with input fields where it is convenient to start the 
free text at the right position after filling the input fields.
(http://de.openoffice.org/servlets/ReadMsg?list=users&msgNo=33143)
Someone else mentioned 8 templates he and his staff uses every day.
Others just agreed to the necessity of that feature.

Perhaps there could be a checkbox in the "save templates"-dialogue (File - 
Templates - Save) you have to check to open new documents at the cursor 
position.

For mba's second example (workflow with differnt editors of one document) I 
don't have a solution - if there will not be the document depending feature mba 
mentions, <SHIFT><F5> must be used (or a simple macro striking this shortcut on 
opening the document).

Bernhard

bedipp's survey has confirmed the importance of a document properties setting 
for "move to last edit position" for templates. 

However mba's idea doesn't apply only to documents saved as templates. I once 
worked as quality manager for a consulting firm with a couple of hundred 
staff. Many of our QA docs opened several pages into the document (ie after 
the table of contents and introductory sections).

Another example is reports: the Executive Summary/TOC/Introduction (ie the 
first page of really useful information) is often preceeded by a title page 
and a revision control page. A document setting to open at an author-defind 
location could be useful in that situation, too, especially as we move more 
deeply into the electronic age (although I have noted above that, in my 
experience, most documents are circulated as pdf - Acrobat's document-specific 
setting to automatically display the bookmark pane is useful in that regard).

I start to have fond feelings for this thread! Anyway. Thanks for the hint to
test for the "modifying author" first. This is absolutely necessary.

Concering the template positioning, I suggest that a macro will do the job much
more reliable than the likeley default setting in OOo 1.1. This was common
agreement between me and the user experience design team. Sure, it is a
trade-off, but its all I can offer for OOo 2.01.

BTW We have engineering commitment for  i33307, i43146, i50902. The spec will be
updated before implementation begins. 

51 votes and a vivid discussion. This will be done for OOo 2.0.
I'll update the spec during the next 2 business days

spec draft done - new sections are highlighted in bright yellow.

I am just so very happy.

I go around singing the praises of OOo to my friends, and they don't understand
why they should switch when they already have MS Office, but this is a reason.
The people have a voice. It is a beautiful thing.

Thanks Matthias for your hard work and compromise.

It's great 

*** Issue 51199 has been marked as a duplicate of this issue. ***

Good news that it made it finally into 2.0. Thanks.

Thanks to Mathias (mmp) for changing the target milestone - it is much better
than any workaround...

Thanks to all of you con-discussants for convincing him of the exigence for that
feature.

That's how community works!

Hi Matthias, all,

My compliments as well for the discussion and the current outcome.

Furthermore I'll try to think about the situation regarding positioning in
tempates (and others). Using a macro is not a problem in corporate
style-environments. But it is an extra effort in other situations.
I do not intend to come with suggestions shortly. And above all I think the
solution as presented now is very OK for this moment.

spec is final - please implement section 6.2 of the spec.

Fixed in cws os65 in
sw/source/ui/uiview/view.cxx

* opens beer.

any ideas which master build might get this cws integrated so that we can 
extensively test it ? ;)

*** Issue 51578 has been marked as a duplicate of this issue. ***

cws os65 can be found on cws03

re-open issue and reassign to es@openoffice.org

reassign to es@openoffice.org

reset resolution to FIXED

ES: verivied in cws os65.
Last Author reopens -> jumps to cursor position
New User opens -> at start of document.

*** Issue 51770 has been marked as a duplicate of this issue. ***

Ok in build src680m117

*** Issue 52219 has been marked as a duplicate of this issue. ***

*** Issue 47364 has been marked as a duplicate of this issue. ***

Hi all,

XP & OOo 1.9.125 Dutch

- I take a blanc doc
- Create an ott from that
- Create an odt from that template
- Ad some text
- Notice that File|Props lists my name at 'made at', same as in
Tools|Options|General|Userdata
- Save the doc
- Re-open it
- But no cursor at the last position :-(
- Sft-F5 doesn't have any effect either (which is correct, target is 2.0.1)

* What am I doing wrong?
* The Tools|Options|OOo|View|Restore is checked (however, according to specs, is
 of no use and will be removed later)
* Meta XML shows <office:document-meta
xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" 
so it should be the proper new fileformat.
* What file /node / prop is the position to be found?

Oeps, I just test an English/US version of OOo.
There it does work.
So it is an translation-issue.
Does it make sense if I look in one of the XML-files?

Thanks,
Cor

Is it possible that you don't have entered your name into the user data? AFAIK
the cursor restore is bound to the equality of user names from last editor and
the person that opens the document. I assume that in case both are empty it is
assumed that they are not the same person.

if both user information & owner/last editor of the document are empty, they are 
not considered the same.

though if it works ok in english version, somebody with corresponding localised 
version should test it.

I'm using 1.9.125 German version and there it works as expected. I make a
change, save the document and close it, reopen it and the cursor is at the place
where I made the last change.

*** Issue 62802 has been marked as a duplicate of this issue. ***

The Restore Editing View function is not working. (version 4.1.13)
After reopening an edited document, the cursor should be at the last place where editing occurred. This worked well until yesterday. Now, all documents open on the front page.
The shortcut Shift+F5 has also failed. It should move the cursor to the last edited point.

I checked that relevant keys are in place.
For example, Tools/customise/shortcut keys/Shift+F5
Also under Function/category/ function/ Shift+F5 indicates it should Restore Editing View.
Any suggestions?

Hi,

This is not for user support. Better ask on our forum:
https://forum.openoffice.org/en/forum/

Did you look if you have a username entered at "Tools - Options - OpenOffice - User Data"?