Issue 128270 - m-dash and n-dash entry requires superfluous leading/trailing space to autocorrect
Summary: m-dash and n-dash entry requires superfluous leading/trailing space to autoco...
Status: CLOSED IRREPRODUCIBLE
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: 4.1.6
Hardware: All All
: P5 (lowest) Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-17 20:44 UTC by Paul Temple
Modified: 2020-05-13 22:37 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Paul Temple 2020-01-17 20:44:30 UTC
This relates to Issue ID 61326 but, in my opinion, that ID's documentation is misleading as it includes a failure to understand formatting rules used by all major publishing houses (who, in the case on en-dash, all conform to English language rules).

Professional publication almost always uses publishing houses (an insignificant number of professional authors finance their own private printing of their work). Therefore, in effect, all authors must follow the rules set by their choice of publishing house. This applies to all types of work including fiction but, ESPECIALLY, to factual works such as scientific books and articles (usually called "papers" or "learned papers").

While, unhelpfully, publishing houses are not fully consistent as their rules go, they are with regard to the en-dash. En-dash is used as a separator in place of " to ", to signifify a range (e.g. 1920 to 1930 can be written as 1920–1930). However, while the word "to" MUST be surrounded by spaces, the en-dash MUST NOT be surrounded by spaces. NO SPACES are allowed by publishing houses when using en-dash to indicate a range. In addition, and seemingly contrary to what is said in case ID 61326, en-dash has NO OTHER FUNCTION except as a range indicator. The en-dash indicator can be used WHENEVER a range is indicated, so can occur between two numbers or between two words, such as "July–November" (I am a professional author and a professional teacher of English.)

Therefore, when one has to enter any space in order to cause autoreplace to change a double hypen (--) to an en-dash (–), since the space(s) added are NOT replaced, the author is required to backtrack and edit out the superfluous spaces that, if present NEVER comply with publishing house rules.  This is true BOTH for a leading space (used in conjunction with the double hyphen to allow autorplace to recognise the double hypen as requiring replacement) and for a trailing space (entry of which triggers the autoreplace). This is work for the author and the function of a word processor should be to replace unnecessary work. 

Thus, my proposal is that the autocorrect function to insert n-dash (–) should be intiated by entering just a double hyphen (--) OR it should replace any of " --" (space hyphen hypen),"-- " (hyphen hypen space), and " -- "space hyphen hypen space), with JUST the n-dash (–) and no leading space.  

At present, the autocorrect function for n-dash serves to implement a grammatical error on users (n-dash properly uses no leading or trailing spaces) and I suggest that the forced imposition of an error on a user's work is not good practice. 
 
Note also that if some users might object to this, that would be equivalent to objecting to software maintaining any grammatical requirement, such as a leading capital letter following the use of a period mark (in the UK called a "full stop"). If people wish to insert a space, this would require that they type a double space before a double hyphen; the traing space and double hyphen would autocorrect to an n-dash leaving the leading space unchanged.

Of course, there would be no issue if users opt to be non-conformant with English language rules but I see that as managed by the typing of double spaces either before or after en-dash, which would allow their inappropriate non-conformance with English language rules while not preventing OpenOffice to be programmed to conform to the rules, as per my proposal.

Regards

Paul
Comment 1 Paul Temple 2020-01-17 20:48:07 UTC
Marked as a defect because the current en-dash autocorrect forces a gramatical (a leading space or trailing space or both) error on the user.
Comment 2 oooforum (fr) 2020-01-20 09:48:50 UTC
(In reply to Paul Temple from comment #0)
> This relates to Issue ID 61326 but, in my opinion, that ID's documentation
> is misleading as it includes a failure to understand formatting rules used
> by all major publishing houses (who, in the case on en-dash, all conform to
> English language rules).
Could you provide a screenshot of this help page?
Comment 3 oooforum (fr) 2020-05-13 11:30:44 UTC
No news from OP

Feel free to reopen and provide requested informations