[Libreoffice-commits] .: Branch 'libreoffice-3-5' - 2 commits - writerfilter/source

[Michael Stahl]

 writerfilter/source/dmapper/ConversionHelper.cxx |    5 +++++
 writerfilter/source/dmapper/DomainMapper.cxx     |    9 +++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

New commits:
commit 0fe856fdbf7696b00ed3fe32890cdb0f7e46c9a5
Author: Muhammad Haggag <mhaggag at gmail.com>
Date:   Wed Feb 1 20:56:12 2012 +0200

    fdo#43398: dmapper: Switch paragraphs to RTL based on the value of w:BiDi.
    
    This is a fix for 43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified.
    
    Cause: dmapper used to treat the presence of a w:BiDi element in a paragraph's properties as an indicator of RTL directionality, which is incorrect. A w:BiDi  element may have a value of 0, indicating LTR.
    
    Fix: Inspect the integral value of w:BiDi elements before switching to RTL.
    (cherry picked from commit d8cb61f5f32247a8bbaf89fb910c015b6107f051)
    
    Change-Id: Id948d9fc9dfb818a502b9de283ac265d0c80cb37
    Signed-off-by: Michael Stahl <mstahl at redhat.com>

diff --git a/writerfilter/source/dmapper/DomainMapper.cxx b/writerfilter/source/dmapper/DomainMapper.cxx
index c2820ee..24cb353 100644
--- a/writerfilter/source/dmapper/DomainMapper.cxx
+++ b/writerfilter/source/dmapper/DomainMapper.cxx
@@ -1837,8 +1837,13 @@ void DomainMapper::sprmWithProps( Sprm& rSprm, PropertyMapPtr rContext, SprmType
         }
         break;  // sprmPOutLvl
     case NS_sprm::LN_PFBiDi:
-            rContext->Insert(PROP_WRITING_MODE, false, uno::makeAny( text::WritingMode2::RL_TB ));
-            rContext->Insert(PROP_PARA_ADJUST, false, uno::makeAny( style::ParagraphAdjust_RIGHT ));
+        {
+            if (nIntValue != 0)
+            {
+                rContext->Insert(PROP_WRITING_MODE, false, uno::makeAny( text::WritingMode2::RL_TB ));
+                rContext->Insert(PROP_PARA_ADJUST, false, uno::makeAny( style::ParagraphAdjust_RIGHT ));
+            }
+        }
 
         break;  // sprmPFBiDi
     case NS_ooxml::LN_EG_SectPrContents_bidi:
commit 33de264435f2f9a92b27222d33c35d85d5c64167
Author: Michael Stahl <mstahl at redhat.com>
Date:   Thu Jul 5 21:12:16 2012 +0200

    writerfilter: workaround for double border import regression:
    
    70a6a4d425558340bb49507975343a3e0a1bdde8 broke the import of "double"
    borders from DOCX and RTF, because writerfilter ends up calling the same
    API as the ODF import filter; unfortunately the proper fix for that is
    2d045cdb69176b280812dda0b813371cf1ac72e2 is more than i would like to
    backport to libreoffice-3-5 so add a compensating workaround that
    makes the DOCX and RTF import filter work again.
    
    Change-Id: I9435760e7d11f09cf54883039fa3af05af308b33

diff --git a/writerfilter/source/dmapper/ConversionHelper.cxx b/writerfilter/source/dmapper/ConversionHelper.cxx
index 4996f00..d87f89d 100644
--- a/writerfilter/source/dmapper/ConversionHelper.cxx
+++ b/writerfilter/source/dmapper/ConversionHelper.cxx
@@ -177,6 +177,11 @@ void MakeBorderLine( sal_Int32 nLineThickness,   sal_Int32 nLineType,
         case 21:
         case 23:
             nLineStyle = DOUBLE;
+            // HACK HACK HACK - only for libreoffice-3-5!
+            // this is a workaround for the fix for fdo#46112, which actually
+            // broke the DOCX/RTF import because the ODF import calls the
+            // same UNO API function: multiply by 3 here to offset divide by 3.
+            nLineThickness *= 3;
             break;
         case 11:
         case 13: //Don't have thin thick thin, so use thick thin