Bug 148704 - Shapes in Calc documents mispositioned in tiled rendering
Summary: Shapes in Calc documents mispositioned in tiled rendering
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shapes
  Show dependency treegraph
 
Reported: 2022-04-21 08:16 UTC by Michael Weghorn
Modified: 2024-07-18 07:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document with shapes (10.37 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-04-21 08:16 UTC, Michael Weghorn
Details
Screencast for Android Viewer (728.58 KB, video/x-matroska)
2022-04-21 08:16 UTC, Michael Weghorn
Details
Screencast for gtktiledviewer (1.26 MB, video/x-matroska)
2022-04-21 08:17 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2022-04-21 08:16:12 UTC
Created attachment 179700 [details]
Sample document with shapes

Steps to reproduce:

1) open the attached Calc doc "shapes.ods" in Android Viewer or gtktiledviewer
2) zoom in and out
3) look at how the text around the shapes is positioned

Actual result:
When zooming in and out, the position of shapes relative to the text changes, e.g. at some zoom levels, the text is even below the shapes.

Expected result:
Relative position of shapes and text should remain the same for all zoom levels.

Reproducible with gtktiledviewer in a current master development build like this:

    ./bin/run gtktiledviewer --lo-path=$(pwd)/instdir/program  /tmp/shapes.ods

Screencasts will be attached.

This is with git master as of commit 5d56255c22c79b72c1cedb48cfe0a200f89bdc66.
Comment 1 Michael Weghorn 2022-04-21 08:16:45 UTC
Created attachment 179701 [details]
Screencast for Android Viewer
Comment 2 Michael Weghorn 2022-04-21 08:17:19 UTC
Created attachment 179702 [details]
Screencast for gtktiledviewer
Comment 3 Michael Weghorn 2022-04-29 07:19:47 UTC
While looking at a different Android issue, I came across this:

> sc/source/ui/view/gridwin4.cxx-    // setup the SdrPage so that drawinglayer works correctly
> sc/source/ui/view/gridwin4.cxx-    ScDrawLayer* pModel = rDoc.GetDrawLayer();
> sc/source/ui/view/gridwin4.cxx-    if (pModel)
> sc/source/ui/view/gridwin4.cxx-    {
> sc/source/ui/view/gridwin4.cxx-        bool bPrintTwipsMsgs = comphelper::LibreOfficeKit::isCompatFlagSet(
> sc/source/ui/view/gridwin4.cxx:                comphelper::LibreOfficeKit::Compat::scPrintTwipsMsgs);
> sc/source/ui/view/gridwin4.cxx-        mpLOKDrawView.reset(bPrintTwipsMsgs ?
> sc/source/ui/view/gridwin4.cxx-            new ScLOKDrawView(
> sc/source/ui/view/gridwin4.cxx-                &rDevice,
> sc/source/ui/view/gridwin4.cxx-                mrViewData) :
> sc/source/ui/view/gridwin4.cxx-            new FmFormView(
> sc/source/ui/view/gridwin4.cxx-                *pModel,
> sc/source/ui/view/gridwin4.cxx-                &rDevice));
> sc/source/ui/view/gridwin4.cxx-
> sc/source/ui/view/gridwin4.cxx-        mpLOKDrawView->SetNegativeX(bLayoutRTL);
> sc/source/ui/view/gridwin4.cxx-        mpLOKDrawView->ShowSdrPage(mpLOKDrawView->GetModel()->GetPage(nTab));
> sc/source/ui/view/gridwin4.cxx-        aOutputData.SetDrawView(mpLOKDrawView.get());
> sc/source/ui/view/gridwin4.cxx-        aOutputData.SetSpellCheckContext(mpSpellCheckCxt.get());
> sc/source/ui/view/gridwin4.cxx-    }

In a quick test, unconditionally setting comphelper::LibreOfficeKit::Compat::scPrintTwipsMsgs as below made rendering work fine in Android Viewer and gtktiledviewer.

The below was just for testing, but I plan to take a closer look at some point whether setting that compat flag for both of them is the way forward.


diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index 462e2e5d25af..36ed36951999 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -6482,6 +6482,9 @@ static int lo_initialize(LibreOfficeKit* pThis, const char* pAppPath, const char
         }
     }
 
+    comphelper::LibreOfficeKit::setCompatFlag(
+        comphelper::LibreOfficeKit::Compat::scPrintTwipsMsgs);
+
     // What stage are we at ?
     if (pThis == nullptr)
     {
Comment 4 Michael Weghorn 2023-04-09 05:11:53 UTC
Unassigning for now, but I might come back to that at some point in time unless anybody else finds time earlier.
Comment 5 Michael Weghorn 2024-07-18 07:44:21 UTC
When setting the option mentioned in comment 3 for Android Viewer, this now results in the text/shapes being even more badly misplaced, the text now partly ending up underneath the shapes in the sample doc.

So it looks like something else has changed in the meantime in addition that would require further changes, i.e. further analysis first.

Quickly tested with this local change on top of current master as of c1b00424f17eaea8f55565dae285521c1ec4d042:

diff --git a/android/source/src/java/org/libreoffice/LOKitTileProvider.java b/android/source/src/java/org/libreoffice/LOKitTileProvider.java
index bbdc9456cf4c..4bd27512a323 100644
--- a/android/source/src/java/org/libreoffice/LOKitTileProvider.java
+++ b/android/source/src/java/org/libreoffice/LOKitTileProvider.java
@@ -63,7 +63,7 @@ class LOKitTileProvider implements TileProvider {
         mMessageCallback = messageCallback;
 
         LibreOfficeKit.putenv("SAL_LOG=+WARN+INFO");
-        LibreOfficeKit.putenv("SAL_LOK_OPTIONS=compact_fonts");
+        LibreOfficeKit.putenv("SAL_LOK_OPTIONS=compact_fonts:sc_print_twips_msgs");
         LibreOfficeKit.init(mContext);
 
         mOffice = new Office(LibreOfficeKit.getLibreOfficeKitHandle());