Bug 67208 - Horizontal rules in old documents are broken: only links in the files
Summary: Horizontal rules in old documents are broken: only links in the files
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
 
Reported: 2013-07-23 07:58 UTC by Cédric Bosdonnat
Modified: 2021-05-14 09:56 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
a sample file containing rules. (9.27 KB, application/vnd.oasis.opendocument.text)
2013-07-23 07:59 UTC, Cédric Bosdonnat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cédric Bosdonnat 2013-07-23 07:58:43 UTC
Files containing horizontal rules dating from before commit 3be15a051444d4d2f805d95e27831d5f466c1497 are broken.

The picture wasn't inserted in the file. A backup solution needs to be implemented to at least show a default rule.

An example rule in content.xml:
<draw:frame draw:style-name="fr1" draw:name="graphics1" text:anchor-type="paragraph" svg:width="5.5417in" svg:height="0.1252in" draw:z-index="0">
          <draw:image xlink:href="../../libreoffice/3.6/solver/unxlngx6.pro/installation/opt/program/../share/gallery/rulers/blurulr2.gif" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
        </draw:frame>

Fixing this would mean to check the link URL for the /gallery/rulers/ string and use a replacement in that case.


The import code to start with could be the method XMLTextFrameContext::CreateChildContext(), the case with  XML_TEXT_FRAME_GRAPHIC == nFrameType

See file xmloff/source/text/XMLTextFrameContext.cxx

See bug 60858 for the original bug report.
Comment 1 Cédric Bosdonnat 2013-07-23 07:59:22 UTC
Created attachment 82857 [details]
a sample file containing rules.
Comment 2 Björn Michaelsen 2013-10-04 18:46:06 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 3 Björn Michaelsen 2014-12-02 10:53:08 UTC
adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 4 superpwnzormegaman 2015-03-04 03:57:30 UTC
Hello opensource noob, but (kindoff) experienced c++'er here.
I did the detection part with:

diff --git a/xmloff/source/text/XMLTextFrameContext.cxx b/xmloff/source/text/XMLTextFrameContext.cxx
index 58ed9b3..0b5e4e8 100644
--- a/xmloff/source/text/XMLTextFrameContext.cxx
+++ b/xmloff/source/text/XMLTextFrameContext.cxx
@@ -721,6 +721,30 @@ void XMLTextFrameContext_Impl::Create( bool /*bHRefOrBase64*/ )
             GetImport().GetTextImport();
         if( !sHRef.isEmpty() )
         {
+            /**
+             * BUG: 67208
+             *
+             * in old documents horizontal rulers are shown as links to
+             * nonexisting images.
+             *
+             * In here we replace them with ...
+             */
+            const OUString matchString = OUString("/gallery/rulers/");
+            const sal_Int32 matchLength = matchString.getLength();
+            for(sal_Int32 i = sHRef.getLength() - matchLength; i > 0; i--){
+                if(sHRef.match(matchString, i)){
+                    SAL_DEBUG("replace something with something here?");
+                }
+                /*
+                 * check to see if we are going deeper than one dir from the end
+                 * of the path, if so stop, because our matching matchStringing is only
+                 * relevant for the last part of the path
+                 */
+                if(sHRef[i+matchLength-1] == '/'){
+                    i = -1;
+                }
+            }
             bool bForceLoad = xTxtImport->IsInsertMode() ||
                                   xTxtImport->IsBlockMode() ||
                                   xTxtImport->IsStylesOnlyMode() ||


But I'm not sure with what I should replace these links.

Also not that this fix will probably break any images that are put into any "/gallery/rulers/" folder, so this path should probably be as long as possible. I tried to reduce the chance of these name clashes by starting the search at the end of the path and going forward up the name untill the first / occurs, assuming that all these ruler styles are directly in the rulers directory, and don't have sub directories (am I right in this?).
Comment 5 Robinson Tryon (qubit) 2015-12-14 06:58:16 UTC Comment hidden (obsolete)
Comment 6 Robinson Tryon (qubit) 2016-02-18 14:52:03 UTC Comment hidden (obsolete)
Comment 7 Matt K 2021-05-14 06:34:16 UTC
How do you insert these lines and is there a purpose for them that is different than would be achieved by inserting a regular image?
Comment 8 Buovjaga 2021-05-14 09:56:35 UTC
(In reply to Matt K from comment #7)
> How do you insert these lines and is there a purpose for them that is
> different than would be achieved by inserting a regular image?

You can't insert them anymore as the feature was removed. The idea for this task was to implement some kind of compatibility feature for old documents. However, as this task is 8 years old and there does not appear to be an actual practical demand, I wonder if we should just drop this.