Status report: consultancy team, week 48, 2023

Status reports
1

Caolan

Mike

  • “Unexpected content when exporting image anchored to paragraph”
    • Prepared the fix for the second problem (no need to emit the
      wrap-emulating br for ReqIF)
  • “Improvements for the LanguageTool integration”
    • Debugging the partial underline problem
    • The problem appears to be the check for isProofreading in
      SwDoc::StartGrammarChecking
    • Why would we not schedule the following paragraphs (or the same para,
      if modified) when already checking this doc’s old data?
    • But it’s just an idle job; how do we check if the paragraphs need
      checking?
    • Possibly we need to check if the content is modified when validating
      …
    • Implemented - simply compare the actual node text with its saved text,
      before processing the response. I can’t repro anymore with the patch, but
      who knows … asked to test.
    • The other problem (of missing suggestions) seems to be what Gokay
      fixed some time ago - porting to master (one change less to complain about)
  • “Writer selection makes crash”
    • no repro with desktop master?
    • repro with online (nice to be able to run from WSL!)
    • problem debugging (both from VS - it only shows code when crashed, and
      from GDB directly)
    • back to printf
    • large dumps, with not the nicest backtraces
    • found how to demangle -
      C++ Code Snippet - Print Stack Backtrace Programmatically with Demangled Function Names - panthema.net
    • anyway, debugging in VS is awesome - disassembly window helped to find
      frames that only listed addresses
    • everything is inside lcl_DeleteRedlines - both creation of the
      problematic SwContentIndex instances (inside SwPaM), and the crash
    • the suspect is the first creation of SwPaM (line 406)
    • it has a strange release() call … why?
      https://gerrit.libreoffice.org/c/core/+/51814/
    • but reverting it indeed reintroduces tdf#106746
    • oh - it’s in transferable creation! Copy to clipboard allows to repro
      on desktop!
    • minimizing, creating upstream bug
    • debugging
    • fixed; submitted to CI
  • tdf#158442
    • My recent patch caused a regression in hybrid PDFs
    • Miklos also sees problems opening DOC files - related?
    • Fixed by checking PK magic number in the tested files
    • tdf#158442 is not resolved by that
    • Problem in boost spirit classic file handling, using strict locking
    • Also it uses char-based file API → can’t open files with names not
      representable in ACP
    • Patching boost
    • While preparing unit tests, had to remove a “ASCII-only file names”
      check from pre-commit hooks…

Tomaz

First-page header and footer from and to DOCX

  • Fixed crash related to cut/paste of header/footer stashed FrameFormat
    • issue happens when running tests, and existed before first header/footer
      refactoring, but it wasn’t triggered due to luck
    • when we “cut” functionality, we create a new SwDoc instance and copy
      content to that, so we can copy again at paste to the target document
    • the issue here is how stashed FrameFormat copying is implemented - we
      just assign the same FrameFormat instance
    • the FrameFormat is dependent on the document used, but the document
      could already be destroyed, which happened when running tests
    • so we crashed on destruction, because document pointer was already
      invalid
    • solution is to properly copy the whole FrameFormat, if we detect we are
      copying into a new document (FrameFormat is associated to another SwDoc
      instance)
  • Got all the tests working (or working around it)
    • pushed to master
  • Finished with this

Upstream bugfix tdf#123396

  • issue is that PNG fallback is used instead of original SVG in flat ODF
    files
  • priority is calculated depending on mime-type
  • mime-type is determined from the file extension, but in flat ODF files,
    there is no filename for the image streams (they are inline - base64 encoded
    streams)
    • so priority could not be determined and it just happens that PNG has
      been chosen
  • each image however has a mime-type attribute in the document itself, so we
    know the mime-type
  • this mime-type however is not used in the MultiImageImportHelper where we
    try to figure out what to do with multiple images
  • so the solution is - transport that mime-type all the way down to the
    MultiImageImportHelperand use that to determine the priority (which image
    should be used)
    • we always use this mime-type unless it is not set, then we try to use
      the filename extension and lastly we try to get the mime-type from the image
      format itself

Miklos