Bug 161195 - Allow Right-to-Left brochure printing in Draw / Impress
Summary: Allow Right-to-Left brochure printing in Draw / Impress
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Mohamed Ali
URL: https://ask.libreoffice.org/t/draw-ri...
Whiteboard: target:25.8.0
Keywords: difficultyMedium, easyHack, skillCpp
Depends on:
Blocks: Print-Dialog RTL-UI RTL
  Show dependency treegraph
 
Reported: 2024-05-21 04:56 UTC by ardv
Modified: 2025-02-17 15:29 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ardv 2024-05-21 04:56:30 UTC
i hope that you add the right to left brochure printing option like in Writer
Comment 1 Stéphane Guillou (stragu) 2024-06-05 05:44:47 UTC
Steps:
0. Tools > Options > Languages and Locales > General > Default languages for documents > tick "Complex Text Layout"
1. In Writer: File > Print > Page Layout > Brochure: dropdown allows changing between LTR and RTL. Feature is inherited from OOo, and Asian language suppo
2. In Draw: File > Print > Page Layout > Brochure

Result: no dropdown to switch between LTR and RTL brochures.
Would make perfect sense to make it available, especially since Draw can be used for creating communication materials suited for single- or multi-sheet brochure printing.
This was also requested in bug 102074, using the use case of printing Manga, usually in RTL direction. However, that report was marked as fixed only for the availability of the dropdown when Asian language support is turned on - still only for Writer.

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Hossein, wondering if this could be an easyHack?
Comment 2 Hossein 2024-06-06 14:02:59 UTC
(In reply to Stéphane Guillou (stragu) from comment #1)
> Hossein, wondering if this could be an easyHack?
Yes, I think so.

Code pointers:

Searching for the string "brochure" leads to the constant STR_PRINTOPTUI_BROCHURE:

$ git grep -i brochure *.hrc

This constant is used in sw/source/core/view/printdata.cxx, which provides such an option in Writer.

This part of code is relevant:

// check if either CJK or CTL is enabled
bool bRTL = SvtCJKOptions::IsCJKFontEnabled() || SvtCTLOptions::IsCTLFontEnabled();

...

if (bRTL)
{
  // create a bool option for brochure RTL dependent on brochure
  uno::Sequence< OUString > aBRTLChoices{ SwResId( STR_PRINTOPTUI_LEFT_SCRIPT),
                                        SwResId( STR_PRINTOPTUI_RIGHT_SCRIPT) };
  vcl::PrinterOptionsHelper::UIControlOptions aBrochureRTLOpt( aBrochurePropertyName, -1, true );
  uno::Sequence<OUString> aBRTLHelpIds { ".HelpID:vcl:PrintDialog:PrintProspectRTL:ListBox" };
  aBrochureRTLOpt.maGroupHint = "LayoutPage";
  // RTL brochure choices
  //      0 : left-to-right
  //      1 : right-to-left
  const sal_Int16 nBRTLChoice = rDefaultPrintData.IsPrintProspectRTL() ? 1 : 0;
  m_aUIProperties[ nIdx++ ].Value = setChoiceListControlOpt("scriptdirection",
                   OUString(),  aBRTLHelpIds, "PrintProspectRTL", aBRTLChoices, nBRTLChoice,
                   uno::Sequence< sal_Bool >(), aBrochureRTLOpt);
}

On the other hand, there is not such thing for LTR/RTL selection in sd/ module, which is relevant here. One can find things related to brochure in sd/ with:

$ git grep -i brochure sd/

Most of the things related to preparing the print dialog is done in sd/source/ui/view/DocumentRenderer.cxx in a method named ProcessResource(). Similar code should be added to the last parts of this function.

The way brochure direction is used in Writer (sw/) can be a blueprint for implementing the same thing in Draw/Impress (sd/).
Comment 3 Mohamed Ali 2024-11-25 16:12:18 UTC
(In reply to Hossein from comment #2)
> (In reply to Stéphane Guillou (stragu) from comment #1)
> > Hossein, wondering if this could be an easyHack?
> Yes, I think so.
> 
> Code pointers:
> 
> Searching for the string "brochure" leads to the constant
> STR_PRINTOPTUI_BROCHURE:
> 
> $ git grep -i brochure *.hrc
> 
> This constant is used in sw/source/core/view/printdata.cxx, which provides
> such an option in Writer.
> 
> This part of code is relevant:
> 
> // check if either CJK or CTL is enabled
> bool bRTL = SvtCJKOptions::IsCJKFontEnabled() ||
> SvtCTLOptions::IsCTLFontEnabled();
> 
> ...
> 
> if (bRTL)
> {
>   // create a bool option for brochure RTL dependent on brochure
>   uno::Sequence< OUString > aBRTLChoices{ SwResId(
> STR_PRINTOPTUI_LEFT_SCRIPT),
>                                         SwResId(
> STR_PRINTOPTUI_RIGHT_SCRIPT) };
>   vcl::PrinterOptionsHelper::UIControlOptions aBrochureRTLOpt(
> aBrochurePropertyName, -1, true );
>   uno::Sequence<OUString> aBRTLHelpIds {
> ".HelpID:vcl:PrintDialog:PrintProspectRTL:ListBox" };
>   aBrochureRTLOpt.maGroupHint = "LayoutPage";
>   // RTL brochure choices
>   //      0 : left-to-right
>   //      1 : right-to-left
>   const sal_Int16 nBRTLChoice = rDefaultPrintData.IsPrintProspectRTL() ? 1 :
> 0;
>   m_aUIProperties[ nIdx++ ].Value =
> setChoiceListControlOpt("scriptdirection",
>                    OUString(),  aBRTLHelpIds, "PrintProspectRTL",
> aBRTLChoices, nBRTLChoice,
>                    uno::Sequence< sal_Bool >(), aBrochureRTLOpt);
> }
> 
> On the other hand, there is not such thing for LTR/RTL selection in sd/
> module, which is relevant here. One can find things related to brochure in
> sd/ with:
> 
> $ git grep -i brochure sd/
> 
> Most of the things related to preparing the print dialog is done in
> sd/source/ui/view/DocumentRenderer.cxx in a method named ProcessResource().
> Similar code should be added to the last parts of this function.
> 
> The way brochure direction is used in Writer (sw/) can be a blueprint for
> implementing the same thing in Draw/Impress (sd/).

I want to set setChoiceListControlOpt with a specific parameter, i_nValue, in sd/source/ui/view/DocumentRenderer.cxx, like how it’s done in sw/source/core/view/printdata.cxx.

But I can't find rDefaultPrintData in sd or anything similar that returns the value I need, which is IsPrintProspectRTL.

Because of this, I cannot call setChoiceListControlOpt with the correct parameter.

Additionally, I can't find a script that distinguishes between RTL or LTR; it seems to be just one option.

What should I do? I was thinking about including rDefaultPrintData from sw into sd, but I'm not sure if this is the right approach.
Comment 4 Commit Notification 2025-02-17 09:08:05 UTC
Mohamed Ali committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/72d766134e374816e88451fa90c70656dde89581

tdf#161195 Allow right-to-left brochure printing in Draw / Impress

It will be available in 25.8.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.
Comment 5 Eyal Rozenberg 2025-02-17 15:29:26 UTC
Hello Mohamed,

 (I'm using the same spelling of your name as Bugzilla, if you prefer a different spelling please say so)

I'm looking at the commit, and there are two things I disapprove of - although one of them is not your fault.

The first and most minor has to do with the conflation between right-to-left direction support in LibreOffice and other things, like CJK script support and complex text layout support. Your code says:

// check if either CJK or CTL is enabled
bool bRTL = SvtCJKOptions::IsCJKFontEnabled() || SvtCTLOptions::IsCTLFontEnabled();

While it might get the job done, the code does not make sense as one reads it. "Fonts" don't have much to do with text direction; and full RTL support should not depend on how fully we enable support for complex text layout or CJK scripts.

The second is that your patch shows no regard for the document's direction in choosing whether a brochure would be printed left to right. It creates a UI control for making that decision, specific to printing. How does this make sense? If the document is RTL, then its printing handling should respect its RTLness; instead, the behavior is:

* Assumes document pages are always paired left-first - regardless of document direction
* Introduce a sui-generis print dialog control
* Flips the order of pairs in an apriori-LTR-ordered array of pairs, before printing

... while one would expect that the "vector of pairs" would already respect the document's direction to begin with; and that no extra UI would be necessary for this particular action.

I don't think this is the right thing to do.