Description: When printing a vertical writing document, the characters is rotated 90 degrees to the right. This happens in Writer vertical writing documents. It doesn't change even if Skia setting is turned off. Steps to Reproduce: 1. Start Writer 2. Input Japanese charactors 3. Select menu [Format]-[Page Style] 4. Click Page tab, Select "Right-to-Left(vertical)" in Text direction, click "OK" 5. Select menu [File]-[Print] 6. Selct "Microsoft Print ot PDF", click "Print" 7. Check the PDF file If you open the sample file, start from step 6 Actual Results: All characters rotate Expected Results: Those characters do not rotate Reproducible: Always User Profile Reset: No Additional Info: Reproduced in the following version: Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: threaded Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded Not reproduced in the following versions: Version: 7.1.6.2 (x64) / LibreOffice Community Build ID: 0e133318fcee89abacd6a7d077e292f1145735c3 CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
Created attachment 175924 [details] Sample vertical document
Created attachment 175925 [details] Comparison of print results Comparison of print results between 7.2.2 and 7.1.6
Created attachment 175926 [details] Comparison of print results The screenshot I attached was small, so I will attach it again
Reproduced. Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL
Also, reproduced with 7.2.1 and 7.2.3. Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL Version: 7.2.3.0.0+ (x64) / LibreOffice Community Build ID: e2e2262e35278a12e716fef3cd61145047ef8680 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL Didn't reproduced with 7.1.6.
Bibisected to the following commit using repo bibisect-win64-7.2. I assume it's more of an implementation error on the side of DWriteTextRenderer that this commit switched to. Adding CC: to Mark Hung. https://cgit.freedesktop.org/libreoffice/core/commit/?id=5686c1aca40beb9514d40c86b4a3780a8a1334ba author Mark Hung <marklh9@gmail.com> 2021-05-02 14:45:45 +0800 committer Mark Hung <marklh9@gmail.com> 2021-05-10 21:14:09 +0200 vcl: use DWriteTextRenderer for vertical writing.
just a guess: https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/CommonSalLayout.cxx?r=5dc3bc1e#403 https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/CommonSalLayout.cxx?r=5dc3bc1e#588 https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/DWriteTextRenderer.cxx?r=677434a5#273 https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/DWriteTextRenderer.cxx?r=677434a5#406 ---- e.g. for U+3042, vertical orientation is Upright, so GlyphItem::IsVertical returns true. https://www.unicode.org/Public/UNIDATA/VerticalOrientation.txt I guess, if tb-rl is specified in Page style, angle = rLayout.GetOrientation(); // angle is set to -900_deg10? I haven't taken log yet. if (isVertical) // true for this time angle += 900_deg10; // angle is set to (-900 + 900) = 0 ? -> drawn upright ? -- I wonder what if we change to the following code // we don't rely on this value // Degree10 angle = rLayout.GetOrientation(); if (!bIsVertical) angle = -900_deg10; ------------------ I haven't investigated much about side effect, though. Some case may really use orientation. One of the cases I'm concerned about is these radio buttons https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/chardlg.cxx?r=d72511ed#2417 and similar rotations may appear in other applications like Draw and Impress. I hope my worries here are just nonsense.
I meant... When I changed to WinFontTransformGuard aTransformGuard(mpRT, fHScale, rLayout, baseline, !pGlyph->IsVertical()); glyph was drawn rotated ON SCREEN
seems I was wrong. need to rethink.
@himajin100000 Printing in vertical layout always uses ExTextOutRenderer[1]. That is, it uses ancient, magical, messy Win32 API, ExtTextOutW, to render the text. To render CJK upright text in vertical writing with ExtTextOutW, one has to prepend a '@' to the font name and call CreateFontIndirectW to create a different font. But for some other characters, one needs to create different font with altered escapement and orientation to force 90 degree rotation. Those were removed in bibisected fault commit[2]. Even if the commit is reverted, I still don't know how to make offset correct for ExtTextOutW. Positions from HarfBuzz doesn't work well with ExtTextOutW. More correct way other than tweaking the position by experiments: - Make DWriteTextOutRednerer works with a printing DC, maybe by create a compatible DC and bitbliting it, or create command list feature introduce in Windows8. - Make Skia works with printing. Check with Luboš Luňák, maybe he has an idea how to print on SKia. - Treat different logical font created with CreateFontIndirectW(), as fallback font. ( i.e. Glyphs that needs a force rotated font has to be renered in fallback layout with the rotated font. ) Non of them are easy for me, but I'll try to come out a commit that revert[2], that at least improves character orienation. [1] https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/winlayout.cxx?r=677434a5#276 [2] https://cgit.freedesktop.org/libreoffice/core/commit/?id=5686c1aca40beb9514d40c86b4a3780a8a1334ba [3] https://docs.microsoft.com/en-us/windows/win32/direct2d/printing-and-command-lists
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.
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.
It's late, but I'll report it. It seems to be resolved in 7.3.2 and 7.2.6. Even at 7.4.0.