Description: Characters rotated when printed in Asian layout mode of vertical writing Printing to real printer device or virtual printer device does reproduce this. but "Export PDF" doesn't problem, Steps to Reproduce: 1. Start Calc 2. Input Japanese sentence 3. Select menu [Format]-[Cells] >>[Alignment] tab >>Enable "Vertically stacked" and "Asian layout mode" 4. Menu >File > Print >> Select real printer device or virtual printer device , for example ”Microsoft Print to PDF" And Print(P). 5. Check the result of printed paper. Actual Results: Vertical Japanese text has rotated. Expected Results: Vertical writing is displayed correctly without rotation Reproducible: Always User Profile Reset: No Additional Info: Reproduced version: Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL Not reproduced version: Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS:Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
Created attachment 174888 [details] Actual result and Expected result
Created attachment 174889 [details] Sample file.
reproduced. Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL Don't reproduced in 7.1.5.
Created attachment 174891 [details] test case with three letters
Created attachment 174892 [details] printed, and processed using 'qpdf --stream-data=uncompress'
Created attachment 174893 [details] exported under VCL_DEBUG_DISABLE_PDFCOMPRESSION=1
I've created an example that MAY POSSIBLY be helpful.
when I opened the PRINTED version, I find this line, so these can be somewhat related. https://opengrok.libreoffice.org/search?full=Tm&path=%22%2Fcore%2Fvcl%2Fsource%2Fgdi%2F%22&project=core cm BT /R9 9.96 Tf 0 -1.00057 1 0 107.52 775.36 Tm [(þ†)0.564439(þˆ)0.564439(þŠ)]TJ ET -- by the way, >Don't reproduced in 7.1.5. I don't have enough time, but bibisect with the following branch would also be helpful for debugging. bibisect-win64-7.2 see https://wiki.documentfoundation.org/QA/Bibisect/Windows#Bibisecting_the_Bug for the steps.
in my machine, the virtual printer "Microsoft Print to PDF" outputs images for characters, not a string. I produced my pdfs with PrimoPdf.
reproduced. Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL
Bug 144222 looks very similar to this, would the kind people here take a look at that one as well? Thanks.
(In reply to Ming Hua from comment #11) > Bug 144222 looks very similar to this, would the kind people here take a > look at that one as well? Thanks. It's certainly a problem that's happening in close position, but the phenomenon is a bit different and it seems difficult to tell if it's related at this point. This issue points to character rotation, and Bug 144222 points to character placement. Also, this issue occurs when printing, not PDF export.
(In reply to JO3EMC from comment #12) > This issue points to character rotation, and Bug 144222 points to character > placement. > Also, this issue occurs when printing, not PDF export. Yes I am aware of the differences. That's why I said they "look similar", and put the other bug in "See Also", instead of suggesting them to be duplicates. My judgment is based on (1) they both involve a very specific layout with same UI options and (2) they both claimed to be regression from 7.1. I'd be very surprised if they turn out to be *not* related to the same (or same set of) commit in the 7.2 development cycle.
(In reply to Ming Hua from comment #13) > Yes I am aware of the differences. That's why I said they "look similar", > and put the other bug in "See Also", instead of suggesting them to be > duplicates. > > My judgment is based on (1) they both involve a very specific layout with > same UI options and (2) they both claimed to be regression from 7.1. > > I'd be very surprised if they turn out to be *not* related to the same (or > same set of) commit in the 7.2 development cycle. Oh, I see. Please forgive me for lack of understanding.
seems my source code pointer in comment 8 was completely wrong. I did bibisection as follows: $ git bisect log # bad: [3a2bb2f0e2e56def58d4ffea7ca5962c674829e3] source 8fdbb8aed1b48734a717d5f98ada566de7204605 # good: [0de175072f79362baeb83b6733b9300d4de5fba4] source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a git bisect start 'latest' 'oldest' # good: [7a711a39141eeaffb2bd55f93e928a8d2f4d42fb] source 3dfb8552eb84eaf831c4c3eb59c398afc87e9174 git bisect good 7a711a39141eeaffb2bd55f93e928a8d2f4d42fb # good: [03bb15e381faa6e4fd958366dfc5bbcdda662ccb] source ff673ce838a5538b1432daf9007c047f6455a5ba git bisect good 03bb15e381faa6e4fd958366dfc5bbcdda662ccb # bad: [09cbda122bd57e44592a6c0147c31e17e2086bf1] source b3cd042285af08a0bdc5dea608d131424d850f9c git bisect bad 09cbda122bd57e44592a6c0147c31e17e2086bf1 # bad: [5ba67aad12ee35e47ed3094a3e0653e5d7fdd045] source 12b6cd0233173323ba0a8dbbc3e1197b92336124 git bisect bad 5ba67aad12ee35e47ed3094a3e0653e5d7fdd045 # bad: [0cfa7202c82b6c4d5859c63dccc23df918b41698] source de16265f55ff2e4e1beb574fcb5b7b894df234f9 git bisect bad 0cfa7202c82b6c4d5859c63dccc23df918b41698 # good: [169f889a8a80410766ea4fd27db31e2cd37552f1] source 7ef207a79e13cbb3a98b03d7370e741f5796186c git bisect good 169f889a8a80410766ea4fd27db31e2cd37552f1 # bad: [39a1914a49b31d3d8e9dadf9bdd37b88b0dac2c4] source 65543a53c4058a6e491bc3ef8ca71970a1bc50b7 git bisect bad 39a1914a49b31d3d8e9dadf9bdd37b88b0dac2c4 # good: [08ca0c0ab02c360c7a8acad6ed0ba5735efa488e] source 06ae35e5e26bf5054598e002cfc6639d844346ab git bisect good 08ca0c0ab02c360c7a8acad6ed0ba5735efa488e # bad: [8a25f4cb4d23cbc3f53157f2c5d45f843727b3cf] source 68c1682929d5b8af95e299a2cfb3fdbb4f97e5ed git bisect bad 8a25f4cb4d23cbc3f53157f2c5d45f843727b3cf # good: [765715d4e6f6283c3e4c95c70d922b2cc8757d11] source f1311618e29315526565797f6edf2918d58f0fe4 git bisect good 765715d4e6f6283c3e4c95c70d922b2cc8757d11 # good: [7997a68e68927123545673be7ff77ef0661489c0] source 60ed173e04838c57c1a73279d01fdad9bdd1575e git bisect good 7997a68e68927123545673be7ff77ef0661489c0 # good: [6f8685012d41bd4bba5b5f4823e9b2107aa77ff6] source 16de54a5c47fbc4691ee099c1f7bb559a8fe11ac git bisect good 6f8685012d41bd4bba5b5f4823e9b2107aa77ff6 # bad: [0c57275cf2750251ad04e32717723c618bc1c28a] source 5686c1aca40beb9514d40c86b4a3780a8a1334ba git bisect bad 0c57275cf2750251ad04e32717723c618bc1c28a # first bad commit: [0c57275cf2750251ad04e32717723c618bc1c28a] source 5686c1aca40beb9514d40c86b4a3780a8a1334ba
(In reply to himajin100000 from comment #15) > # first bad commit: [0c57275cf2750251ad04e32717723c618bc1c28a] source > 5686c1aca40beb9514d40c86b4a3780a8a1334ba https://git.libreoffice.org/core/+/5686c1aca40beb9514d40c86b4a3780a8a1334ba
*** Bug 146070 has been marked as a duplicate of this bug. ***
Mark Hung committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6720e9569d7ab6c20616ec6b97e5d4a56948908b tdf#145322, tdf#144378 fix printing for vertical writing It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 176822 [details] I confirmed the fix in 7.4.0.alpha0. However, the position is off. Thank you very much for fixing the program. I confirmed the fix in 7.4.0.alpha0. However, the position is off. Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7e5af164b7d293dd410710bed411e1ca64bbecf7 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL
Mark Hung committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/3c2836972613ff418d76306d958a8ef85ff18afe tdf#145322, tdf#144378 fix printing for vertical writing It will be available in 7.3.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mark Hung committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/25b77b4a684695e8948c8a97902c8e9de80b446e tdf#145322, tdf#144378 fix printing for vertical writing It will be available in 7.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 176988 [details] The rotation format was printed out correctly I tested printing with 'Microsoft Print to PDF' and 'CubePDF'. The rotation format was printed out correctly. Version: 7.2.5.1 (x64) / LibreOffice Community Build ID: 6d497ff5e83a906a307eb25cce314d40c0b8624f CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL