1. 24 May, 2019 2 kayıt (commit)
  2. 22 May, 2019 1 kayıt (commit)
  3. 20 May, 2019 11 kayıt (commit)
  4. 13 May, 2019 1 kayıt (commit)
  5. 12 May, 2019 1 kayıt (commit)
  6. 10 May, 2019 1 kayıt (commit)
  7. 09 May, 2019 1 kayıt (commit)
  8. 07 May, 2019 1 kayıt (commit)
    • Miklos Vajna's avatar
      tdf#124594 DOCX filter: don't extend margins from effects for rotated shapes · 65420c21
      Miklos Vajna yazdı
      Regression from commit a5a836d8 (DOCX
      filter: effect extent should be part of the margin, 2014-12-04), the
      problem was that extending margins as-is based on the effect extent
      values only work correctly in case of non-rotated shapes.
      
      For example, with 90 degree clockwise rotation the top effect extent
      should extend the right margin, etc. Fix the bug by limiting this
      extension to the non-rotated scenario.
      
      Test the behavior at a layout level, so in case later the effect extent
      feature is implemented, it won't be necessary to adjust the test.
      
      Change-Id: I97271bbb7c079951980b436cb8d8e5e54eeead55
      Reviewed-on: https://gerrit.libreoffice.org/71878
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.com>
      65420c21
  9. 02 May, 2019 1 kayıt (commit)
  10. 30 Nis, 2019 2 kayıt (commit)
    • Justin Luth's avatar
      tdf#123636 writerfilter: handle deferred breaks on frames · f6f53f76
      Justin Luth yazdı
      ...similar to handling breaks before shapes in lcl_startShape.
      
      Three different examples found to create/split a paragraph.
      Which one to use? (addDummy, m_bIsSplitPara, and
      lcl_startCharacterGroup). SplitPara is not good because the
      paragraph properties probably should not be copied to the
      dummy paragraph (like numbering for example). Slightly
      modified the lcl_startChar example to ensure that the dummy
      paragraph doesn't steal a part of the properties, but is
      only default properties plus page-break.
      
      This doesn't export very well, so roundtripping is very poor.
      
      Research Note: There exists a compat flag showBreaksInFrames
      (Display Page/Column Breaks Present in Frames)
      "This element specifies whether applications should
      honor the presence of page and/or column breaks which are
      present within the contents of paragraphs which have been
      defined as frames using the framePr element."
      --Currently, LO does nothing with this flag. Probably too
      exotic and irrelevant (word 2003 era?).
      
      No existing unit tests found that have isSet(pg_brk) frames.
      
      Change-Id: I29f815355401c7af8b347a3ed9d0298bc9b27b93
      Reviewed-on: https://gerrit.libreoffice.org/71255
      Tested-by: Jenkins
      Reviewed-by: 's avatarJustin Luth <justin_luth@sil.org>
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.com>
      f6f53f76
    • Noel Grandin's avatar
      improve loplugin:stringconstant · dd8d5e57
      Noel Grandin yazdı
      to find more places we can elide the OUString() constructor at call
      sites
      
      Change-Id: Ie09f3c61f2c4b4959c97dc98ebcbaf7c51d5d713
      Reviewed-on: https://gerrit.libreoffice.org/71514
      Tested-by: Jenkins
      Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
      dd8d5e57
  11. 29 Nis, 2019 1 kayıt (commit)
  12. 26 Nis, 2019 1 kayıt (commit)
    • László Németh's avatar
      tdf#67207 DOCX mail merge: fix export/import of database fields · 071c3309
      László Németh yazdı
      to support the registered databases (containing ODS, XLSX
      sheet or ODT text table data sources).
      
      Now database fields don't lose their database connection,
      and File->Print can merge mails after DOCX export/import, if
      the LO instance has got a registered database with the same
      name and table, as in saved in w:settings/w:mailMerge/w:query
      element of the DOCX document in the form of
      
      SELECT * FROM [databaseName].dbo.[tableName]$
      
      query.
      
      Notes:
      
      – This fix supports only single table usage.
      
      – The exported DOCX document is editable in MSO, too,
        without losing the database connection in LO later.
      
      Change-Id: I97826b7ee7defd0243dbaffa0325c5b11dd2c0d1
      Reviewed-on: https://gerrit.libreoffice.org/71228
      Tested-by: Jenkins
      Reviewed-by: 's avatarLászló Németh <nemeth@numbertext.org>
      071c3309
  13. 25 Nis, 2019 1 kayıt (commit)
    • Justin Luth's avatar
      related tdf#123636 writerfilter: split newline also if PAGE_BREAK · 89e44da1
      Justin Luth yazdı
      ...but only with old MSWord compat flag SplitPgBreakAndParaMark.
      
      All of the other cases (COLUMN_BREAK and non-empty runs) split
      the paragraph, so why not here?  This document shows it is needed,
      but only for SplitPgBreakAndParaMark documents.
      
      Note: Word 2003 doesn't display "modern" docx well in this regard.
      It adds extra paragraphs where it shouldn't. There are already
      example unit tests that ensure that extra paragraphs aren't written
      for SplitPgBreakAndParaMark == false.
      
      The actual bug's document is not related to the compatibility flag.
      That will be handled in separate commit.
      
      Change-Id: I27399780c909663f9a2b21974a5b385bea67f9ec
      Reviewed-on: https://gerrit.libreoffice.org/70835
      Tested-by: Jenkins
      Reviewed-by: 's avatarJustin Luth <justin_luth@sil.org>
      89e44da1
  14. 15 Nis, 2019 2 kayıt (commit)
  15. 14 Nis, 2019 1 kayıt (commit)
  16. 13 Nis, 2019 1 kayıt (commit)
  17. 12 Nis, 2019 1 kayıt (commit)
  18. 10 Nis, 2019 1 kayıt (commit)
    • Michael Stahl's avatar
      writerfilter: implement RTF derived styles defaulting · 3d74ddd1
      Michael Stahl yazdı
      It turns out that the situation fixed in commit
      1be0a3fa also applies to the definition
      of the styles themselves.
      
      To implement the same style import as Word, the style definitions need
      to be stored twice: once as read from the file, and another time with
      attributes defaulted and deduplicated vs. the parent style; the second
      representation is then sent to the domain mapper.
      
      To make this easier, add a bool parameter to cloneAndDeduplicate()
      to disable the implicit pPr dereferencing that happens when creating the
      hard formatted paragraph properties (this could potentially be cleaned
      up further if those paragraph properties would use pPr wrapper
      themselves).
      
      Also implement defaulting of line spacing in getDefaultSPRM().
      
      Change-Id: I4810e917697b3af244e5dbdd7f5a45b4767c93fc
      Reviewed-on: https://gerrit.libreoffice.org/70320
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.com>
      3d74ddd1
  19. 01 Nis, 2019 1 kayıt (commit)
  20. 29 Mar, 2019 1 kayıt (commit)
  21. 28 Mar, 2019 1 kayıt (commit)
  22. 25 Mar, 2019 3 kayıt (commit)
  23. 20 Mar, 2019 1 kayıt (commit)
  24. 13 Mar, 2019 1 kayıt (commit)
  25. 12 Mar, 2019 1 kayıt (commit)
    • Miklos Vajna's avatar
      tdf#123104 DOCX import: fix lack of vertical merge due to rounding · e502463f
      Miklos Vajna yazdı
      Regression from commit 29cbbad6 (DOCX
      import: fix rounding error in table cell widths, 2014-11-07), which
      changed truncation to rounding for the twips -> 1/10000th of relative
      width conversion during import, but left export unchanged.
      
      But adapting the export is not that easy: one part would be the
      std::unique() call in
      WW8TableNodeInfoInner::getColumnWidthsBasedOnAllRows() to not require
      exact comparison, but doing so has it own side effects (multiple failing
      tests).
      
      So just revert the mentioned commit, as a minor rounding error is much
      better than a broken vertical merge. And once it's clear how to adapt
      export at the same time, this rounding on the import side can be
      re-introduced.
      
      Change-Id: I9e01ea5cc2c2f8aabe1e21cb8118c9c0e2c45494
      Reviewed-on: https://gerrit.libreoffice.org/69065
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.com>
      e502463f