Bug 75967 - Draw: position/orientation of symbols in vertical text wrong when exported to PDF
Summary: Draw: position/orientation of symbols in vertical text wrong when exported to...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
Depends on:
Blocks: PDF-Import-Draw PDF-Export
  Show dependency treegraph
 
Reported: 2014-03-10 07:46 UTC by Daniel Chung
Modified: 2019-12-03 14:15 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
test.zip - vertical text (25.33 KB, application/zip)
2015-10-04 02:22 UTC, Daniel Chung
Details
export from LO 5.2 (4.45 KB, application/x-pilot)
2016-04-24 19:48 UTC, raal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Chung 2014-03-10 07:46:39 UTC
This may be related to:
https://bugs.freedesktop.org/show_bug.cgi?id=45684

ENVIRONMENT:

1. Windows 7, Chinese (Taiwan, i.e. traditional or complex character version)

2. LibreOffice Draw, version 4.2.1 release

--

1. Use font 標楷體 size 24 points, to Input a block of vertical Chinese text:
()二○一四─

2. The Chinese parentheses will be automatically re-oriented for vertical text.
This is good.

3. The circle (○) (commonly used to denote zero) is positioned correctly and the stoke (─) is automatically re-oriented for vertical text.  Good.

4. Export this file to PDF.

PROBLEM:

1. The circle (○) is slightly off-axis toward thes right.  This may be related to problem "2" below.

2. The stroke (─) remains horizontal. This should be re-oriented the same way as displayed in LibreOffice Draw.

If you cannot reproduce this problem, ask me for a screen shot.

Thanks.

Qiyao
Comment 1 Daniel Chung 2014-03-11 02:05:23 UTC
Correction:

1. Sorry, please ignore the part about the stroke (—) being misoriented in the PDF.  This stroke character is correct.  I was probably using the horizntal table-drawing charecter (─).

Thanks.

Qiyao
Comment 2 Kevin Suo 2014-06-29 16:01:13 UTC
This is not a localization issue. Set component to Drawing.
Comment 3 steve -_- 2014-10-28 00:48:47 UTC
Can you please provide a test document so this can be tested against and subsequently be confirmed. If your document contains sensitive data, please clear that or replace it with random information.

Setting to NEEDINFO until more detail is provided.

After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :)
Comment 4 QA Administrators 2015-05-06 14:15:09 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2015-06-08 14:26:53 UTC Comment hidden (obsolete)
Comment 6 Daniel Chung 2015-10-04 02:22:28 UTC
Created attachment 119254 [details]
test.zip - vertical text
Comment 7 Daniel Chung 2015-10-04 02:24:43 UTC
Please check attachment "test.zip".
It has the same text written horizontally and vertically.
Punctuation marks are automatically re-oriented by the Chinese character engine.
The character of concern is ○, which is a unicode symbol, commonly
used as Chinese "zero" because a separate unicode symbol was invented for
the Chinese "zero".
You can see that when exported to PDF, its position is off.

Thanks.

Daniel
Comment 8 Buovjaga 2015-10-09 18:50:32 UTC
Bug does not meet the criteria for Status 'REOPENED'
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/REOPENED#Criteria
Status -> UNCONFIRMED
Comment 9 Kevin Loughrey 2016-03-07 21:43:10 UTC
This is a suggestion for enhancement it is not a bug and I don't want to appear to be ungrateful for the wonderful efforts of this team.  When I came to this page I did not see a button providing for people to make a suggestion.  Maybe I have missed it.  If not, then that is a shortcoming which needs, I think, to be remedied because constructive suggestions are of great value to an endeavour such as this.

My suggestion relates to importing a PDF into LibreOffice Draw.  It may be that this suggestion is better placed with the team involved in the importation of documents of another format and not the LibreOffice team.  If so, and if this suggestion is thought to have merit I would be grateful if it could be passed on.

I suggest there is a need in LibreOffice Draw for one to be able to select all characters within a range of text boxes or all of the text boxes on a page or all of the text boxes within a document and to change their font so that the text will properly sit within the boundaries of the page and more closely resemble the appearance of the text on the PDF.  At present, when you import a PDF document into Draw, you find you have to then go to each text box individually, select the text, and then change the font until you have achieved a similar look to the original document.

I hope this suggestion is helpful.

With best wishes and sincere thanks for your efforts

Kevin Loughrey CPEng
Comment 10 Kevin Suo 2016-03-08 00:23:05 UTC
(In reply to Kevin Loughrey from comment #9)
Hi, your issue described above is nothing to do with this bug. Please filed new bugs for your issues, and make sure you file one bug report for
r each of the issues, do not mix two different things together within one bug report. 

If you think it's an enhancement request, set the field IMPORTANCE as Enhancement in your bug report.

Thanks.
Comment 11 raal 2016-04-24 19:48:30 UTC
Created attachment 124608 [details]
export from LO 5.2

confirm.
Version: 5.2.0.0.alpha0+
Build ID: 5bb308a9ad16f6002486a60e4a753693818580b6
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-04-20_19:07:06
Comment 12 Heiko Tietze 2016-05-10 12:47:37 UTC
Looks like a duplicate of 58173. But since it's Chinese I'm not sure. Please verify once 58173 is fixed.
Comment 13 QA Administrators 2017-10-30 08:30:19 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2019-12-03 14:15:09 UTC
Dear Daniel Chung,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug