Bug 88365 - [SVG] re-base: text label not displayed correctly after Insert or Open (problem with: group object <g text-anchor="end">)
Summary: [SVG] re-base: text label not displayed correctly after Insert or Open (probl...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.3.3.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:svg, regression
Depends on:
Blocks: SVG-Import SVG-Open
  Show dependency treegraph
 
Reported: 2015-01-13 11:04 UTC by Zac
Modified: 2019-06-14 13:27 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
How the SVG looks in firefox (25.67 KB, application/pdf)
2015-01-13 11:04 UTC, Zac
Details
How the same SVG looks in LO (13.74 KB, application/pdf)
2015-01-13 11:07 UTC, Zac
Details
The SVG-File (excerpt taken from line 135 ff) (12.28 KB, application/xml)
2015-01-13 11:10 UTC, Zac
Details
LO file (46.79 KB, application/vnd.oasis.opendocument.text)
2015-01-13 11:11 UTC, Zac
Details
Screenshot of SVG import showing only white picture (43.30 KB, image/png)
2015-01-31 00:58 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zac 2015-01-13 11:04:51 UTC
Created attachment 112160 [details]
How the SVG looks in firefox

<g transform="translate(1645.9,65.4)" stroke="none" fill="black" font-family="Calibri" font-size="20.00"  font-weight="bold"  text-anchor="end">
		<text >
		<tspan font-family="Calibri"  >dir</tspan>
		<tspan font-family="Calibri"  font-size="16.0"  dy="6.00px">1</tspan>
		<tspan font-family="Calibri"  font-size="20.0"  dy="-6.00px"> ist noch</tspan>
		<tspan font-family="Calibri"  font-size="16.0"  dy="-10.00px">2</tspan>
		<tspan font-size="20.0" dy="10.00">####</tspan>
		</text>
</g>

yields that all tspan objects in this group are alinged wrong.
if text-anchor="start" is used the alignment of the group members are as expected but the whole group then is missaligned to the Objects outside of the group
Comment 1 Zac 2015-01-13 11:07:59 UTC
Created attachment 112161 [details]
How the same SVG looks in LO
Comment 2 Zac 2015-01-13 11:10:11 UTC
Created attachment 112162 [details]
The SVG-File (excerpt taken from line 135 ff)
Comment 3 Zac 2015-01-13 11:11:11 UTC
Created attachment 112163 [details]
LO file
Comment 4 Zac 2015-01-13 11:19:15 UTC
Because I can not edit the description:

it seems that the text-anchor is propagated to all the group members instead of using it only for the alignment of the whole group
Comment 5 Robinson Tryon (qubit) 2015-01-14 12:20:29 UTC
(In reply to Zac from comment #4)
> Because I can not edit the description:
> 
> it seems that the text-anchor is propagated to all the group members instead
> of using it only for the alignment of the whole group

Looks like attachment 112162 [details] is your repro document. The examples of how the document renders in other software is appreciated as well. Please provide steps to reproduce the problem (Open in Draw? Insert into Writer? etc..), and then change status back to UNCONFIRMED. Thanks!

Status -> NEEDINFO
Comment 6 Zac 2015-01-14 12:54:30 UTC
Sorry I don't know what you are talking about.

The attachment 112162 [details] is the Svg file wich is imported to LO.by insert picture from file (i guess Einfügen->Bild->aus Datei)
 
and how the file is renderd in LO you see in the attachment named 
"How the same SVG looks in LO"(sorry don't know how to add a link here) 

To see how other software (like Firefox) renderes open  "How the SVG looks in firefox" or open the SVG-File in Firefox als file://....
Comment 7 Robinson Tryon (qubit) 2015-01-14 17:52:05 UTC
TESTING on Ubuntu 14.04 + LO 4.4.0.2
And Firefox 34.0

(In reply to Zac from comment #6)
> Sorry I don't know what you are talking about.
> 

Here's a step of repro steps that one can follow like a recipe:

REPRO Steps: 
> 
0) View attachment 112162 [details] in Firefox

Looks like a sinusoidal graph.

1) Download attachment 112162 [details]
2) Open Writer
3) Insert -> Image -> (downloaded attachment)
4) Compare rendering in Writer with rendering in Firefox

RESULT:
- Text label "dir 1 ist noch 2 ####" displays legibly in FF 34, but is illegible in LibreOffice after Insert.

Status -> NEW
Whiteboard -> filter:svgInsert

I also tested svgOpen in Draw
- Text label doesn't appear when the file is opened in Draw
Whiteboard -> filter:svgOpen
Comment 8 Buovjaga 2015-01-16 16:10:51 UTC
Works in 3.5.0.
Already broken in 4.3.3

Ubuntu 14.10 64-bit 
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

Version: 4.3.3.2
Build ID: 430m0(Build:2)
Comment 9 Michael Weghorn 2015-01-31 00:58:48 UTC
Created attachment 112976 [details]
Screenshot of SVG import showing only white picture

I tried to bibisect this on Debian Jessie (x86-64).

Inserting svg images (at least for the example image provided here) seems to have been much more broken for some commits in this range.
In all the commits that I skipped in the bisect (s. log below), no real image was imported (just a white frame, s. attachment).


bibisect result:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189
a67b874d60de1f1a44bef57a53a7b8a84db0ba58
46f9a799a00ba869957d7aa7650cae7fd2501394
d73160956706b297f4a7043d35e229f2e8566d5f
183a576d94de9a9439d580c8b81f335ab57cdbdc
221bf5c0db153e24c67ff29fe614af7cc010a356
79e02001f27d33b3b478324ab6fba5683413b4d9
e5973caebe5b9637f93a4da008d76b33b9d5ff6a
1f14665c5624bc7a502738aa8f4f2bd70a211e72
ba6eb41acb8df58f3009920f8ab8b32a3e1b764e
99f63b2b53c0e22baac045d54f502508d7150fef
We cannot bisect more!

------

$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
git bisect start 'latest' 'last35onmaster'
# bad: [34eab3946c46bb7273ba4ca395db9c4421dd232f] source-hash-e962805b31074d6b6a2ed0db6452769448337553
git bisect bad 34eab3946c46bb7273ba4ca395db9c4421dd232f
# good: [2e2d1aeff80dcbe390f6c3fbc54d6c8de81b0a0e] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect good 2e2d1aeff80dcbe390f6c3fbc54d6c8de81b0a0e
# bad: [9ac72638fdc1adf45f17c71f66baf9b20b606891] source-hash-1ed4210d8e6cbf1b25cd1eb8666be6578cc45845
git bisect bad 9ac72638fdc1adf45f17c71f66baf9b20b606891
# bad: [f0250a5564d9cdd406d788062cff81319971ccae] source-hash-db99a31c4e4e7c74d4c4bb7caa747a5752a32757
git bisect bad f0250a5564d9cdd406d788062cff81319971ccae
# bad: [5809284e8a6f97fe3b5beb037b6b80eeb9fe1058] source-hash-246ffb108c7e1f762f8d497750ad2414b85b99ef
git bisect bad 5809284e8a6f97fe3b5beb037b6b80eeb9fe1058
# skip: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
git bisect skip ba6eb41acb8df58f3009920f8ab8b32a3e1b764e
# skip: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73
git bisect skip 79e02001f27d33b3b478324ab6fba5683413b4d9
# skip: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef
git bisect skip 183a576d94de9a9439d580c8b81f335ab57cdbdc
# good: [bd5c49f162a09d173164447720e74257027c6efc] source-hash-f260c656da4457c5d87c161bdd43ad3023d07472
git bisect good bd5c49f162a09d173164447720e74257027c6efc
# good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# skip: [7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189] source-hash-a1ac2538e9b287444500618ab4d2f0f06c25cf34
git bisect skip 7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189
# skip: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
git bisect skip a67b874d60de1f1a44bef57a53a7b8a84db0ba58
# skip: [e5973caebe5b9637f93a4da008d76b33b9d5ff6a] source-hash-683758efb22d08a4cf211a6d985148f513da2a90
git bisect skip e5973caebe5b9637f93a4da008d76b33b9d5ff6a
# skip: [d73160956706b297f4a7043d35e229f2e8566d5f] source-hash-44b96a2fce52b6e3e683dc917fab219cf75001db
git bisect skip d73160956706b297f4a7043d35e229f2e8566d5f
# good: [fae90325861bbddd2af90937d29d91637c96661a] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588
git bisect good fae90325861bbddd2af90937d29d91637c96661a
# skip: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74
git bisect skip 221bf5c0db153e24c67ff29fe614af7cc010a356
# skip: [46f9a799a00ba869957d7aa7650cae7fd2501394] source-hash-a43a76cd5aa2f145f2cb43fcdbc8f21fb6c89af0
git bisect skip 46f9a799a00ba869957d7aa7650cae7fd2501394
# skip: [1f14665c5624bc7a502738aa8f4f2bd70a211e72] source-hash-d85fd8a85501547d5bb87822d2589a07aed7f2d6
git bisect skip 1f14665c5624bc7a502738aa8f4f2bd70a211e72
# bad: [99f63b2b53c0e22baac045d54f502508d7150fef] source-hash-d38a2e3ea04d354492df18aa16d2304babe87dfb
git bisect bad 99f63b2b53c0e22baac045d54f502508d7150fef
# only skipped commits left to test
# possible first bad commit: [99f63b2b53c0e22baac045d54f502508d7150fef] source-hash-d38a2e3ea04d354492df18aa16d2304babe87dfb
# possible first bad commit: [1f14665c5624bc7a502738aa8f4f2bd70a211e72] source-hash-d85fd8a85501547d5bb87822d2589a07aed7f2d6
# possible first bad commit: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73
# possible first bad commit: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74
# possible first bad commit: [46f9a799a00ba869957d7aa7650cae7fd2501394] source-hash-a43a76cd5aa2f145f2cb43fcdbc8f21fb6c89af0
# possible first bad commit: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
# possible first bad commit: [7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189] source-hash-a1ac2538e9b287444500618ab4d2f0f06c25cf34
# possible first bad commit: [d73160956706b297f4a7043d35e229f2e8566d5f] source-hash-44b96a2fce52b6e3e683dc917fab219cf75001db
# possible first bad commit: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef
# possible first bad commit: [e5973caebe5b9637f93a4da008d76b33b9d5ff6a] source-hash-683758efb22d08a4cf211a6d985148f513da2a90
# possible first bad commit: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
Comment 10 Matthew Francis 2015-01-31 02:41:58 UTC
@Michael - if you bibisect a bug to find the transition between states A and B, and find that there is an unexpected state C in the middle (in this case, A, B, and C are "good rendering", "bad rendering" and "blank" respectively), the best thing to do is to break off and start again to separately find transitions A-C and C-B - just pick the commit hash of any instance of C you come across as your mid point.

So in this case we can find that "good rendering" becomes "blank" as of

# first bad commit: [a08143f4bae3d6658dd756b42b6f343298d1f48c] source-hash-b7822657fa67e7265d07f5852057e975e9efae0d

and "blank" becomes "bad rendering" as of

# first bad commit: [99f63b2b53c0e22baac045d54f502508d7150fef] source-hash-d38a2e3ea04d354492df18aa16d2304babe87dfb


(when finding the boundary of two "bad" states, you may have to hold in mind that "good" means "before" and "bad" means "after")
Comment 11 Michael Weghorn 2015-01-31 06:07:02 UTC
(In reply to Matthew Francis from comment #10)
> @Michael - if you bibisect a bug to find the transition between states A and
> B, and find that there is an unexpected state C in the middle (in this case,
> A, B, and C are "good rendering", "bad rendering" and "blank" respectively),
> the best thing to do is to break off and start again to separately find
> transitions A-C and C-B - just pick the commit hash of any instance of C you
> come across as your mid point.

@Matthew: Thank you for explaining. I am always grateful to receive feedback and tips on how to do things (better).
Comment 12 Matthew Francis 2015-01-31 14:29:05 UTC
It seems that the point at which the original rendering changed to blank was the below commit. This isn't directly relevant to the question of what happened to the SVG rendering, as it only hides it - but selectively reverting this commit at points across the "blank" range might reveal more if we are lucky


commit c0ce7ca4884f7f6d1016bd1dbcc22066cb4a7797
Author: Tomaž Vajngerl <quikee@gmail.com>
Date:   Sat Jul 7 13:07:03 2012 +0200

    Prescale image with Bitmap::Scale to improve quality.
    
    In OutputDevice, when sending the Bitmap to native renderer, use
    Bitmap::Scale operation to improve quality when doing sub-sampling.
    With this Bitmaps in certain Widgets will look a lot better.
    
    Cleanup and translate comments, and move sal_Bool to bool in outdev2.cxx
    
    Change-Id: Ice28537414e10b9e6b403df35c6104ffc7db7785
Comment 13 Matthew Francis 2015-02-01 05:51:26 UTC
Working through the range identified above while reverting the problem commit, I can see that the SVG in the file gets broken more than one additional way in the middle, but the main point appears to be:

commit 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70
Author: Michael Meeks <michael.meeks@suse.com>
Date:   Tue Oct 9 12:22:23 2012 +0100

    re-base on ALv2 code. Includes (at least) relevant parts of:
......
        IP clearance: #118466# This patch removes librsvg, libcroco, libgsf, ...


i.e. it's probably the replacement of librsvg that triggered the change in appearance. Unfortunately that means the only way to fix the problem is from scratch, in the new code.

The above is an import from AOO, but AOO 4.1.1 also exhibits the same rendering problem so it's never been fixed over there either.
Comment 14 Robinson Tryon (qubit) 2015-12-10 03:44:23 UTC Comment hidden (obsolete)
Comment 15 Xisco Faulí 2016-09-26 15:29:10 UTC
Adding Cc: to Michael Meeks
Comment 16 QA Administrators 2017-10-30 08:32:39 UTC Comment hidden (obsolete)
Comment 17 jasper.olbrich 2018-06-10 14:37:53 UTC
Bug is still present

Version: 5.4.6.2
Build ID: 1:5.4.6-0ubuntu0.17.10.1
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

Complete example to reproduce:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   width="10cm"
   height="6cm"
   version="1.1">

  <style>
    text {font-family: sans-serif; font-size: 10pt;}
    .it {font-style: italic;}
  </style>

  <line x1="5cm" y1="0cm" x2="5cm" y2="6cm" stroke="#000000" />

  <text text-anchor="start" x="5cm" y="1cm">
    <tspan class="it">italic</tspan> upright
  </text>
  <text text-anchor="middle" x="5cm" y="3cm">
  <tspan class="it">italic</tspan> upright
  </text>
  <text text-anchor="end" x="5cm" y="5cm">
  <tspan class="it">italic</tspan> upright
  </text>
</svg>

Looks as intended in Firefox and Inkscape, garbled in LibreOffice
Comment 18 Roman Kuznetsov 2018-06-18 20:32:48 UTC
still repro in LO 6.1 beta 2
Comment 19 Xisco Faulí 2019-05-14 13:48:50 UTC
Still reproducible in

Version: 6.3.0.0.alpha0+
Build ID: 630db80d17616d635cf2e5f1d5a0852428b794a3
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 20 Carlo Ciarrocchi 2019-06-14 13:27:51 UTC
It may be a general problem of tspan rather than a text-anchor bug. Specifying a text-anchor different than "start" makes the differences worse and therefore easier to spot, but similar problems are reported in bugs 97663, 103888