Apache OpenOffice (AOO) Bugzilla – Issue 112240
When ICU >=4.4 is used, automatic line break handeled incorrectly when caused by a closing parenthesis/square bracket.
Last modified: 2017-05-20 10:30:58 UTC
When an automatic line break is caused by a closing parenthesis (that is, it makes the last word too long for that line), only the parenthesis itself breaks to the next line, while the word attached to it remains on the previous line. Steps to reproduce: 1. Open a new Writer document. 2. Write a line that fits exactly into the current page width. 3. Enter a closing parenthesis ), causing the last word on that line to break. 4. Only the parenthesis break. This only happens with a closing (right) parenthesis, an opening parenthesis behaves correctly (both the parenthesis and the word break). Using a closing square bracket results in the same problem. However, this does not happen when using a closing curly bracket.
Created attachment 69882 [details] Sample document.
Created attachment 69883 [details] Sample screenshot.
Forgot to mention: my OS is Arch Linux.
Cannot reproduce this with Windows and SUSE Linux. Do you work with OOo downloaded from openoffice.org or the one provided by Arch Linux?
Plus to MRU's question: does this happen with other fonts than "Nimbus Mono L"
mru: Packages provided by Arch Linux - 'openoffice-base-beta 3.2.1_ooo320_m19'. Package 'openoffice-base 3.2.0-3' exhibits the same behavior. es: Happens with every font I've tried - mono, sans and serif fonts.
Please try the OOo version from our site. It sounds like a problem of the version of your distro.
Are there any other alternatives to confirm/solve this issue? I have downloaded the OOo version from the site, and it contains a series of RPM files, a format with which I have very little experience (Arch Linux uses a different packaging system). I'm not eager to toy around with it for fear of messing up my installation. However, if you think this is the best way to proceed I'll go ahead and try to install it anyway. That being said, before opening this issue I posted for help on a forum (neither OOo's nor Arch Linux's), and another Arch user using the exact same package as myself didn't have this issue, while an Ubuntu 10.04 user reported that the problem exists for him too (using OOo 3.2.0).
So we "might" exclude a distro bug (?)... @HDU: what do you think about the first description and the screenshot?
Confirming. Yes, this behaviour is independent of the platform. Handling parenthesis, brackets, braces etc. smarter would be a worthwhile improvement. Also see the discussion in issue 105623 on this topic. Another thing that is worth pointing out on the topic of start-of-line or end-of-line chars is that OOo already has the feature "forbidden chars", but only for CJK-Layout. Use Tools->Options->Language- >EnableAsian to enable the CJK-UI elements, then look at the tabpage Tools->Options->Language- >AsianLayout->LastChars or FirstChars. Maybe this concept should be available for all scripts. IMHO a solution based on smarter parenthesis/brace/bracket handling would be better compared to the approach used in the forbidden-chars feature.
*** Issue 113637 has been marked as a duplicate of this issue. ***
Author of the duplicate bug http://www.openoffice.org/issues/show_bug.cgi?id=113637 I confirm issue with OOO320m12 on Mandriva 2010.1 (font Liberation Serif), language: French. It's a major bug: we cannot publish serious documents with such mistakes (closing brackets alone after a line break)
I confirm this bug in Debian Sid. OO version: 3.2.1-5
I confirm this issue in ooo 3.2.0 This is a regression since ooo 3.1.1 (working fine in this version) This is not a file issue (a file made and saved with 3.1.1, then opended with 3.2.0 acts bad). Note that inserting a "No-width no break" character does NOT make the parenthesis to stay with the word left from it. The "No-width no break" character is the one that (should) make the two adjacent characters stay together when wrapping lines. To access it : Tools --> Options... --> Languages Check "Enabled for complex text layout (CTL)" Then it is accessible there : Insert --> Formatting Mark --> No-width no break As beurt says, I think this is a MAJOR regression, since nothing can be published with this issue, and the most obvious workaround ("No-width no break" character) does NOT work. System tested : ooo 3.2.0 on Mandriva 2010.1 KDE (bug here) ooo 3.2.0 on Mandriva 2010.1 Gnome (bug here) ooo 3.1.1 on Mandriva 2010.0 KDE (no bug here) Tested with many different fonts.
I just had this issue with a closing parenthesis under Debian Lenny (ooo-build 3.2.1.4, Debian package 1:3.2.1-6). However, inserting a No-width no-break special character per nowahn's instructions solved my problem (whereas it didn't work for nowahn).
same observation here (Debian testing ). This is my version: 1:3.2.1-7 0 500 http://ftp.debian.de sid/main Packages Wrong Wrapping of Parenthesis was an issue as early as in 2004, but then it was fixed. Now it seems to re-occur.
Another Mandriva 2010.1 user chiming in. Version: 3.2.0.9 - OOO320m12 (Build:9483) Packages: openoffice.org-3.2-4.1mdv2010.1 Language: English I noticed there's been some discussion of this (same/similar/related?) issue on the Debian bug tracker today: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601078 This comment by Charles Plessy looks like a particularly promising nugget: --QUOTE-- Of course, as René noted, the key difference is probably that 3.2.1-7ubuntu1 depends on libicu42 and 3.2.1-9 depends on libicu44. I investigated the differences between the versions 4.2 and 4.4 of icu, in particular in the directory “source/data/unidata/”. Support for parenthesis seem to have changed while switching from Unicode 5.1 to 5.2. In particluar, the right parenthesis and right square bracket, but not the right curly bracket have been moved from a ‘Close_Punctuation’ (CL) to a ‘Close_Parenthesis’ (CP) category. This completely fits with the symptoms that were also reported to the openoffice bug tracker (http://qa.openoffice.org/issues/show_bug.cgi?id=112240). Do you this is enough to reassign this bug to the libicu44 package ? -- END QUOTE -- Note that Charles links back to here. My own ICU package is: libicu44-4.4-2mdv2010.1 Anyway, hope this might help, and this bug gets my vote.
Thanks for the info; this difference between ICU42 and ICU44 is very interesting. I'm not sure whether and how Writer uses the character classification for its line breaking though. If it does it should treat CP like CL for line breaking.
Over at the Debian bug tracker René Engelhard recommended that Charles post his discovery to bugs.freedesktop.org (who I then presume must be the developers/maintainers of libicu). Charles has done so, and the place from where to watch and hope might now be there: https://bugs.freedesktop.org/show_bug.cgi?id=31271 Interestingly it appears that René has had his own suspicions about libicu44 since late October. I've got my fingers crossed (though I might just revert to libicu42 in the mean time -- barring a major dependency mess....).
@hdu: Line breaking uses character classification, see i18npool/source/breakiterator/data/line.txt ICU 4.2 does not know CP Close_Parenthesis class, so we can't define this before we switch to a recent ICU. Grabbing issue for spare time account.
Created attachment 75640 [details] here's a quick and easy fix anyway
oookayyyy.. In cws locales34: changeset f7c1450c8c30 http://hg.services.openoffice.org/cws/locales34/changeset/f7c1450c8c30 M configure M configure.in M i18npool/source/breakiterator/makefile.mk M icu/icuversion.mk M set_soenv.in You can observe the progress and possible integration date of CWS locales34 at http://tools.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Flocales34
Reassigning to QA for verification.
Note to QA: just verify that there is no regression with the standard build. The additional bracket handling comes only into play if ICU >= 4.4 is used, e.g. in a build against system ICU.
Verified in CWS locales34.