Actually, I'm wondering whether the "Replaces dashes" entry in the Options tab should take care of it. That means that, for instance, 12--13 should give unbreakable space+en dash+unbreakable space. At the moment, it gives just an em dash which is completely inappropriate, at least in French.

I changed the title because I think this issue is specific to French, in English normal spaces with en-dash should be OK.

hi, is it still an issue with 4.1.2.3?

Created attachment 91338 [details]
character replacement in Writer

LibreOffice 
Versie: 4.2.0.1 
Build ID: 7bf567613a536ded11709b952950c9e8f7181a4a

The AutoCorrect table has "insert unbreakable space in French text" 
switched on by Default ( see attachment "character replacement in Writer".

I am unsure if behaviour is wrong or good. Alessandro can you help?

(In reply to comment #3)
> hi, is it still an issue with 4.1.2.3?

Hello tommy27!

Yes, with 4.1.3.2 it still is.

(In reply to comment #5)
> LibreOffice 
> Versie: 4.2.0.1 
> Build ID: 7bf567613a536ded11709b952950c9e8f7181a4a
> 
> The AutoCorrect table has "insert unbreakable space in French text" 
> switched on by Default ( see attachment "character replacement in Writer".
> 
> I am unsure if behaviour is wrong or good. Alessandro can you help?

Hello Luc!

Yes, this function ought to be enabled, but unfortunately it doesn't apply to dashes, it works with colons, semicolons, exclamation marks, question marks and quotation marks, but not with dashes.

Too bad.

On pc Debian x86-64 with master sources updated today, I can reproduce this.

Eike: any idea/codepointer?

I found in editeng/source/misc/svxacorr.cxx this:
    613 bool SvxAutoCorrect::FnAddNonBrkSpace(
    614                                 SvxAutoCorrDoc& rDoc, const OUString& rTxt,
    615                                 sal_Int32, sal_Int32 nEndPos,
    616                                 LanguageType eLang )
    617 {
    618     bool bRet = false;
    619 
    620     CharClass& rCC = GetCharClass( eLang );
    621 
    622     if ( rCC.getLanguageTag().getLanguage() == "fr" )
    623     {
    624         bool bFrCA = (rCC.getLanguageTag().getCountry() == "CA");
    625         OUString allChars = ":;?!%";

I tried to insert a dash in allChars but make debugrun indicated this:
warn:rtl.string:16396:1:sal/rtl/strtmpl.cxx:1269: rtl_uString_newFromLiteral - Found char > 127
So I tried this:
bool bIsSpecial = (allChars.indexOf( cChar ) != -1) || (cChar == '–');
but had:
/home/julien/compile-libreoffice/libreoffice/editeng/source/misc/svxacorr.cxx:632:74: error: multi-character character constant [-Werror=multichar]
         bool bIsSpecial = (allChars.indexOf( cChar ) != -1) || (cChar == '–');

I succeeded in building this part by using OUString but it still fails.
Quite stuck now:-(

(In reply to comment #9)

OUString aNbsp("\xc2\xa0", 2, RTL_TEXTENCODING_UTF8);

Thank you Andras for the tip.
I used it, then I noticed too SvxAutoCorrect::NeedsHardspaceAutocorr and added this test:
cChar == ((sal_Unicode) 0x2013)

But even with this, we don't enter in FnAddNonBrkSpace.
I'm not sure but perhaps it's because en-dash is already the result of an autocorrection.

I'm stuck here, even when typing unicode with Ctrl+Shift+U then 2013, I don't succeed in replacing the space by unbreaking space before en-dash.

As long as the unbreakable space is a fixed width space, it has to be optional to keep the justification, see bug 41652.

please grab an august 4.4.x daily build and test new wildcard autocorrect patterns as described in https://bugs.freedesktop.org/show_bug.cgi?id=55292#c19

we need to know if the new feature may have side effects with french punctuation and unbreakable spaces.

please French users give an update of this bug current status and tell if things changed using wildcard patterns (see https://goo.gl/8uDZOX ) or the new emoji feature (available just in 5.0.0 see: https://goo.gl/LA5XzK )

On pc Debian x86-64 with master sources updated today, I could still reproduce this.

This request should be dropped and closed.

In some cases only, there is a need for unbreakable spaces before and after the en-dash.

But in many cases, it’s required to add an unbreakable space after the en-dash and a normal space before (opening dash), and an unbreakable before the en-dash and a normal space after (closing dash).

Example:
Ils ont – quoi qu’il arrive à présent – perdu la partie.

In the “Lexique des règles typographiques de l’Imprimerie nationale”, no unbreakable spaces are required before and after.

As it’s not possible to guess what the user want to do, we should do nothing.

good explanation.
I set status to WONTFIX