If one wants to use special symbols for things like copyright, trademark, etc: e.g.
one has to type a space before and after the "(C)", "(tm)", (R), characters.
But these symbols should NOT be preceded by a space in the final document, so the AutoCorrect function forces the typist to remove the unwanted extra space manually, so that, for example, "Sony ™ Corporation" becomes Sony™ Corporation"
Likewise, when one wants an n-dash to indicate a range of numbers such as dates, pages, etc., e.g.
one is forced to a space before and after the double hyphen, and then delete both of the extra unwanted spaces manually.
SURELY Writer should accept "(C)", "(tm)", "(R)", and "--" without requiring a space before and after? What is the point of requiring those extra keystrokes?
And if, for some good reason that I can't think of, Writer does have to have those spaces, then surely when it AutoCorrects those characters and replaces them with the required special symbols, it ought to get rid of the unwanted spaces?
ti otbain what you look for you need to use wildcard autocorrection which is a new feature of 4.2.x (feature is full functional in 18.104.22.168 and above)
enter the autocorrect replacement table and add an entry like:
.*(tm) --> ™
it will solve the issue about the blank space
I set status to RESOLVED WORKSFORME
feel free to reopen if this doesn't work
more about wildcard autocorrection here:
Thanks for this.
I have now successfully set AutoCorrect to replace ".*--" such that when I type [alphanumeric character][hyphen][hyphen][space] I get an n-dash "–" with no preceding space; so that's a great improvement.
But are you saying I can make it remove the suffix space as well?
".*--.*" does not do it for me.
don't know if it can be user for suffix as well... you have to play with it.
But it still leaves the original question: surely the default behaviour of AutoCorrect for these special symbols is simply WRONG (or at least totally unhelpful and counter-productive), and should thus be considered as a bug that needs fixing?!
Just because there is a work-around (which only half-works anyway) does not mean that the bug has been fixed!
0--.* --> 0–
1--.* --> 1–
2--.* --> 2–
it should fix both the "space before" and "space after issues"
I also ask advise from Lazlo Nemeth who's the author of wildcard autocorrection to see if there's a smarter way to set a rule for double of triple digit numbers as well, since the "2--.*" rule won't work with 12--, 342-- etc. etc.
I tried the syntax .*2--.* but it doesn't work like .*--.*
As I showed with my original examples, one is almost always dealing with 2-, 3-, or 4-digit numerals:
financial years 2013–2014
So this is an *extremely* incomplete work-around to the original bug, not a solution to it.
as you can read in my previous post I'm aware that is a workaround not proficient for double digits and more, so I asked advise to an expert developer.
so please, don't be so impatient and try to be more gentle, showing more respect for people who's spending time trying to help you... you should really adjust the "tone" of your posts.
I apologise if my tone seemed rude or impatient. I really do appreciate the help you guys are trying to give me.
It's just that it seems to me that the community's valuable time and energy should be spent on creating real solutions, not work-arounds.
(In reply to comment #9)
> It's just that it seems to me that the community's valuable time and energy
> should be spent on creating real solutions, not work-arounds.
so you are complaining again... please avoid this type of comment that do not help fixing things but just piss of the people who's trying to help.
you opened a bug report yesterday and after just 1 hour you already got a solution that fixed the special symbols (© ™ ®) issues.
after 14 hours you received another hint that fixed the "number dash" issue for single digits only, and a developers has already been alerted to ask for a better solution for double and triple digits, which I agree with you is not yet resolved.
so it seems to me that the time and energy of the community (which is mainly composed by volunteers) are showing good results in a very limited amount of time.
I'm also confident that Lazlo will find a solution to improve the wildcard autocorrection and use it in the scenario you describe.
we need to understand why the ".*--.*" doesn't do what we are expecting from it.
please be patient and show appreciation for what has been done till now. :-)
OK, if I still seem impatient I am expressing myself badly. Apologies!
I have been living with this "problem" for at least a year, but it only this week that I decided to try to get a proper solution. I spent a considerable amount of time reading the Help documentation etc. before posting a bug report.
Clearly I am not the first person to have raised the issue; see here, for example: http://ask.libreoffice.org/en/question/11581/automatically-place-en-not-em-dashes-between-numbers/
If the response to my bug report had been: "We're aware of the problem, and working on it", that would have been fine. I would have been patient and maybe sent a reminder 3 or 6 months later.
But to be offered an imperfect work-around and to have the status changed to "RESOLVED" did not seem to me to be a good way to proceed. I hope you see why I sent my series of follow-up messages, and am sorry if they seemed impatient or ungrateful
(In reply to comment #11)
> I have been living with this "problem" for at least a year, but it only this
> week that I decided to try to get a proper solution. I spent a considerable
> amount of time reading the Help documentation etc. before posting a bug
Ok. the right place to raise bugs is Bugzilla.
next time don't wait 1 year before doing it. the earlier you post a report the earlier QA and devs will pay attention to it.
> Clearly I am not the first person to have raised the issue; see here, for
sure, I have no doubt that this issue can annoy other people.
nut the "ask LibO" site is meant for user support, tips and trick etc. etc.
again, if you wanna file a bug you have to do it in Bugzilla.
> If the response to my bug report had been: "We're aware of the problem, and
> working on it", that would have been fine. I would have been patient and
> maybe sent a reminder 3 or 6 months later.
> But to be offered an imperfect work-around and to have the status changed to
> "RESOLVED" did not seem to me to be a good way to proceed. I hope you see
> why I sent my series of follow-up messages, and am sorry if they seemed
> impatient or ungrateful
read again comment 1 and expecially this 2 lines that I quote here:
> I set status to RESOLVED WORKSFORME
> feel free to reopen if this doesn't work
so there's really nothing you can complain about it...
a solution was offered to you, status was changed to FIXED but I said that you were *FREE* to reopen if it did not work... that's a correct way to proceed, and I have nothing to regret about it.
it seems to me that anytime you apologize for "expressing badly" just soon after doing it, you start with another polemic which still sounds ungrateful and inappropriate.
now, let's stop this game that's not contributing at all in fixing the bug.
the situation is the "we are aware of the bug and will work to find a solution".
consider that it's summer and I don't know when the specific developer will take a look at it.
in the meantime use wildcard autocorrect to deal with a consistent part of your problems and wait with patience for a complete solution.
Laszlo Nemeth committed a patch related to this issue.
It has been pushed to "master":
fdo#81571 autocorrect doesn't need space before (c), (r), (tm)...
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Fixed autocorrect patterns. Thanks for your bug report!
just to add that the whole en-dash/em-dash autocorrect thing needs some specific autocorrect entries to cover all possible corner case as described here:
thanks again Lazlo for the fix.