well, this issue is still on the status "unconfirmed"
Please let me know, if you need any further details to treat this bug
as serious

rgds
Martin

FME->Martin: "...still not solved..."? Is there already another bug
for this issue? Then one of these should be set to "duplicate". 
Ok, the last space of a line is still there, of course it is. You
surely don't want it to be deleted from your paragraph. But it is not
shown and adopts the formatting of the text in front of it. So in your
example the space should have the height of the arial 10pt font and a
width of 0. Please provide a bugdoc with a detailed description of how
to reproduce this bug.

Created attachment 3947 [details]
example for the line-end-bug

@fme

well, I did not really understood what you ment: Will you accept it as
a bug or not ?

1. "still not solved..." means, that it is not solved to me, and that
it had been reported to the moderator before, for passing it on. 
Regarding the known sideeffects, there will be a lot of duplicates,
which will be difficult to find, as the summary will read different

2. 
 <quote>
 the last space of a line is still there, of course it is.
 You surely don't want it to be deleted from your paragraph.
 </quote>
well this is the lack in concept.
In principle, I do not want to have anything in any file, which I can
not control, direct or indirect. 
However, it is an idea for a workaround: if you can not or will not
keep the last known/used format in memory, glue it to a letter you
will always have, the "default last space", and if the pc or net can
crashes, you will have something in the file. Okay, might work. 

But this has a basic hypothesis: working - in writing - is straight
forward from left to right - so the "last unseen letter" moves always
to the end. 
In an office-situation this is wrong: text is always reused, and in
most cases, text is deleted with backspace and re-entered from the end.
And by that, it is nonsense to have an unseen letter with a different
format than that, you just deleted and re-enter. check it out: annoying.

3.
 <quote>
 But it is not shown and adopts the formatting of the text in front 
 of  it. 
 </quote>
I doubt that one can handle the above stated problems finally successful.
However, at actual you are wrong: It does not work.

Please check out the attached example.

Martin

FME->Martin: I had a first look at your bugdoc and obviously we were
talking about different things. I was talking about line breaks. The
last space in a line is 'hidden', i.e., it was no width, if there is a
line break behind that space. So please ignore my first statement. 

I think I start to understand what you mean. What you call "the last
unseen space" is not a space. There is no additional, unseen space in
your text. Believe it or not, it's a feature. Let me explain. Assume
you have some text with a hard formatting, e.g., you manually assigned
a font via the toolbar. Type some text, the manually asigned font is
used for this. The feature is this: if you press "right arrow" behind
the last character in this line, the font changes to the default font
of the applied paragraph style. 
But still I cannot reproduce your bug. I'll reassign this issue to our QA.

FME->SBA: Could you please have a look at this?

@ FME
 the manually asigned font is used for this. 
 The feature is this: if you   press "right arrow" behind the last
 character in this line, the font changes to the default font of 
 the applied paragraph style. 

Yes, you got it - it changes - and it can not be controlled !!
so it is not a feature, it is a bug.
Note: One can repair the results, but working seriously does not mean,
you like to repair anything, the did by misinterpreting the user.
So I wrote this and really like to have this bug confirmed.
Lets see ..

Martin

hallo

Would you mind to check the status of this issue
and revert?
Thanks
Martin

I understood, this is something to the basics. 
So better hands-off?

However, it is the most anoying bug in OOo (absolut contrary to
all-day-office-use), so you will need to find decision:
you can solve it - take it as enhancement in future time - or treat it
as what it is, a bug. 
I like to know.

Martin

changed:
os: all (it is the same on NT and Linux)
version: all (102)
priority: P2 (I treat it as sever)

rgds
Martin

Martin, what you call a bug is in fact a very useful feature since
many years. If you are at the end of the paragraph that has some hard
formatting attributes assigned and press the cursor right key, you
move behind the attributes first. The next time you press the cursor
right key, you move in the next paragraph. That's a very clear
behavior, and I don't think that it is anoying. In fact, it is very
useful. Consider the situation where a hyperlink ends at the end of a
paragraph, and you want to enter some text. How do you do that? You
either can use some menus and switch of the hyperlink, or you press
the right cursor key once, and can enter your text directly.

With the knowledge what happens when pressing the right cursor key,
can you please describe why you still think this behavior is anoying.
From my point of view, it very seldom happens that hard formatting
attributes are at the end of a paragraph, because most paragraph end
with a ".", and this character normally will not carry hard attributes. 

@Michael
At first thanks for taking care. However, you are wrong.

the behavior is described correctly: the last in a paragraph is the
default paragraph-format, assigned to a "no-letter". 

As I am going to understand, why this issue has been implemented as a
feature, it might be a good idea to talk about the sense:

a) in an office, you use forms, formletters, small notes, tables in
text etc. Nearly every writing-line will be ended by using the <CR>,
this gives a "hard ended paragraph", next is new. 
And: The one who types in is responsible for the outcome.

b) In long textes (epic, for newspapers etc), hard formatted
paragraphs are crazy: paragraphs belongs together by content, final
formatting is made by someone different, the layouter, you have to
avoid the use of the <CR>.

That where the story starts. And I am no writer, I need it in the office.

Your example: 
<Quote>: ".... a hyperlink ends at the end of a paragraph" <unquote>
and how do I find the gap to enter new text? 
If you need to enter text, you can not "reset" to
"from-the-cursor-position-on" (a bug also?). To make it possible to
continue writing, you need to have a tricky workaround: assign the
default paragraph to "nothing". But this is a trick, and will work in
typical situations only, yes, i.e. if I were a writer, which I am not. 
And, bytheway, it is inconsistent also: "Default" will reset the
paragraph-style to default, but using this with a selection, it will
assign a default-format to single letters, all okay. So OOo has the
possibilities to easyly switch between formated and unformated/default
text, but this feature will overide it, this is Inconstistent.

In offices, most letters are reused, content is changed by deleting it
from the back and reenter something new. That is normal. But not with
OOo, as this way it will destroy the format assigned to, what you just
deleted.  
Just to make it clear: You reuse text, and have to be aware, that a
smart but uncontrollable feature overrides what you like to see. This
not funny, and well, I have always problems with smart features doing
unexpected things.

This feature has a reason and a history, but for me the outcome is a
bug. So it has to have a solution. 
An it should not be difficult to have the feature as : 
- leave the hard formated text as long as the user likes it´- incl.<CR>
- have a checkbock for the option: new paragragh with last or default
format
- have right-click/hot-key for the cursor for  "from-now-on-by-default"

When you have these feature implemented, the tricky stuff with the
default-format is no longer neccessary and the line-end-bug is solved.  
my suggestion, I hope I made it clear.
Martin

P.S.:
the missing "search<CR>+replace<blank>" is a bug, that also belongs
somehow to this issue. hope you understand this too.

an old issue, but still good, isn't it ?
Not solved in 103 

Martin



P.S.:
But: to mention this:
 the hard line-break (new paragraph) is now searchable/deletable. that
is good. bad luck: the hard line-break (new line only) not.

The issue issue description gets a little bit too long and confusing.
Please write a new issue "ENHANCEMENT" to make the reset of 
attributes pressing right arrow key at the end of the line optional + 
make the users aware about thius feature (Help pop-up or so...).
Thanx

closed

oops
I have not had the time to lookup for things in here for a couple of 
days. So, seeing this I am really surprised.

frankly: Saying I do not understand where the problem is, so I close 
this issue, will be no way to qualify OpenSource projects, neither 
this nor others. You may take this as an good advice for the future. 
And, as I started this issue, I like to be asked, if I am satisfied 
with closing this.

So, in short words: 
The smart feature of "falling back" to the default style at the Line-
end turns out to be contra-productive. Thats what I wrote this and 
that is, bytheway, why you do not have this feature in MS/Corel/Lotus 
etc..

Well, OO.o is a very much developer-driven project. This is a use-
complaint (not to bother you with decision-maker). So I am going to 
reopen this issue and treat this as a test, if we can find another 
way so solve problems like this, I mean the bug itself as the way on 
how to settle things like this with the reporter.

regards
Martin Heger 

Martin, we didn't simply close the bug, but we asked you to submit a
new one, that has the type Enhancement. The reason for this was that
the behavior you describe in fact is a feature that many people find
useful. So the only thing one could do is to make this behavior
optional. Eric asked you to submit a new issue for this feature
request and closed the bug. Please apologize that I will close the
bug, too, but submitting a new enhancement request is in fact the
correct action here.

This task is 'resolved invalid' and will be closed now.
If you have more details to reproduce the task, please reopen it.

This task is 'resolved invalid' and will be closed now.
If you can give more details to reproduce the problem, please re-open it.

... closed

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

info

no changes in OOo 1.1.1 and still at level unconfirmed at the 
http://qa.openoffice.org/issues/show_bug.cgi?id=13995 
which had be opened to substitute this one. 

mh

at actual this issue is still in dispute
here

http://qa.openoffice.org/issues/show_bug.cgi?id=13592

martin