Summary: | Layout of User Data form in Preferences too narrow | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Jan te Kiefte <jan.te.kiefte> |
Component: | UI | Assignee: | Caolán McNamara <caolanm> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | trivial | ||
Priority: | low | CC: | caolanm, gautier.sophie, LibreOffice, robert.roth.off, serval2412 |
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | target:4.1.0 | ||
i915 platform: | i915 features: | ||
Attachments: |
Annotated screenshot
screenshot on master sources Screenshot of Address form |
Description
Jan te Kiefte
2010-10-14 03:48:45 UTC
I wonder can you provide a screen shot? Created attachment 39787 [details]
Annotated screenshot
Please note that in some countries longer zip codes are used. My zip for example is 1013 AW [Reproducible] with "LibreOffice 3.3.0 RC1 - WIN XP German UI [OOO330m17 (build 3.3.0.1". For me the panes are not too narrow, but I see, it can be too short for some needs. And if the pane for zip code will we enlarged, we will get a complaint from Iceland because we waste room ;-) Concerning paraph: It seems to be common sense in business to use 2 characters in general, but we should no force users to do so. @Sophie, can you help with a hint? Here <http://de.wikipedia.org/wiki/Liste_der_Postleitsysteme> I found that some countries use until 10 characters (Brasilia, USA), I wonder whether that's considered in those localizations? [This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html Created attachment 65210 [details]
screenshot on master sources
On pc Debian x86-64, with master sources updated today, I tried to reproduce the problem.
It seems there's enough place now.
Jan te Kiefte: could you give a try to a newer LO version (last one is 3.5.5) ?
Created attachment 65220 [details]
Screenshot of Address form
1. For Initials I tried "J.B." and the second dot seems truncated;
2. For Zip I tried "1013AW" and the final W is partly truncated.
(Zip codes for the Netherlands consist of four digits and two letters, optionally separated by a space, like "1013 AW".
1. For Initials I tried "J.B." and the second dot seems truncated; 2. For Zip I tried "1013AW" and the final W is partly truncated. (Zip codes for the Netherlands consist of four digits and two letters, optionally separated by a space, like "1013 AW". You meant with 3.5.5 ? (In reply to comment #9) > You meant with 3.5.5 ? Sure, LibreOffice 3.5.5.3 Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21 Ok thank you for your feedback, I put it back to "New" status. Based on a quick run-through ok the Postal codes wiki page [1] a postal code can be up to 14 characters long (South Korea), so that should fit all postal codes. [1] http://en.wikipedia.org/wiki/List_of_postal_codes Caolán: one for you? (thinking about your work on converting src->ui) Yeah, at least probably, and if not makes it easier to fix. This page is currently queued for conversion at sw/uiconfig/swriter/ui/libuserdata.ui it needs to be moved into the right place in cui and the code there adapted to use it, at which point this bug either goes away, or some relatively small tweaks will do that. wrt. "a postal code can be up to 14 characters long (South Korea)" I believe that "NNNNNN (NNN-NNN)" means that the format is a 6 digit code of "NNNNNN", alternatively written as "NNN-NNN" rather than an actual 14char postal code. Maybe leaving space for 9 is a acceptable default. yoinking this now that this tab page has bubbled to the top of the conversion queue Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c2ff9d048addd680799bf4aa28c5bb7b68eec71 Resolves: fdo#30862 move user options page to cui and adapt code 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.