Created attachment 112161 [details]
How the same SVG looks in LO

Created attachment 112162 [details]
The SVG-File (excerpt taken from line 135 ff)

Created attachment 112163 [details]
LO file

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

(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

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://....

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

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)

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

@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")

(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).

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

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.

Adding Cc: to Michael Meeks

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

still repro in LO 6.1 beta 2

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

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

Still reproducible in 7.2:

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

And also in the latest 7.3 master:

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 18e49d2b998ba69d5363d25d285ee6fd188a698d
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

(In reply to Carlo Ciarrocchi from comment #20)
> 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

The problem still exists even without tspan, although it is less visible. Please look at the last line of text: the end of the text is not tangent to the vertical line, as it should be. If you zoom in and out, you will see the text position changes, and this change is visible compared to the position of the vertical line.

<?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">Normal upright</text>
  <text text-anchor="middle" x="5cm" y="3cm">Normal upright</text>
  <text text-anchor="end" x="5cm" y="5cm">Normal upright</text>

</svg>

Created attachment 175432 [details]
Sample svg showing the effect of using tspan and different text-anchors

This example shows the problem in a more visible way.

Instead of using English alphabets for the text, Unicode block characters (█ and ░) are used to demonstrate the text positioning. There are 6 lines of text in the image. Each 2 lines have a similar text, each consisting of two pieces of text. 3 different text-anchors with the usage (+/-) of tspan, create the total 6 different lines.

For each 2 similar text lines, the first line uses span and the text pieces are displayed wrongly and it is marked as red. The second line does not use the tspan, and it is displayed (somewhat) correctly. Please note that if you look closer, even in a green line, the location is not perfect and there is a visible misplacement, but it is much better than a red line.

Created attachment 175433 [details]
PDF from LO 7.3 dev showing the effect of using tspan and different text-anchors

This is the PDF output from 'wrong-text-rendering-anchor-span.svg' created by the latest LibreOffice 7.3 Dev master, which shows the wrong positioning of the text with tspan and different text-anchors.

Ignoring the visible but small positioning error when there is no tspan (of course, only for a moment), one can say that the text-anchor is only applied to the tspan and not the rest of the text, which is the wrong behavior.

(In reply to Buovjaga from comment #8)
> 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)

The text part from attachment 112162 [details] is rendered as blank for me. I am using Ubuntu 20.04 x86_64.

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

I don't think it is a regression.

Created attachment 177008 [details]
PDF output from sin1.svg using LibreOffice 3.5

The text part is blank in the output.

Ubuntu 20.04 x86_64
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

(In reply to Hossein from comment #29)
> Created attachment 177008 [details]
> PDF output from sin1.svg using LibreOffice 3.5
> 
> The text part is blank in the output.
> 
> Ubuntu 20.04 x86_64
> LibreOffice 3.5.0rc3 
> Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

The text part is blank in 3.6.7.2 and 4.1.2.3, but it is visible in 6.4.0.3 (but with the bug described here).

Created attachment 177009 [details]
PDF from LO 3.6 showing that the different text-anchors were ignored

This is the output from attachment 175432 [details] converted to PDF by LibreOffice 3.6.7.2 Linux x86-64. As can be seen in the output, the different text-anchors were ignored.

With the attachment and PDF outputs from the previous versions of LibreOffice, I think this is not a regression. If you know a good commit, please create a PDF from the sin1.svg, and attach it.

The problem is described in comment 27: "the text-anchor is only applied to the tspan and not the rest of the text".

Dear Hossein,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assign it back to yourself if you're still working on this.

This is a duplicate of bug 151103. Working on a fix for it

*** This bug has been marked as a duplicate of bug 151103 ***