Description: It is unclear to me if the issue is on the TexMaths side or on the LibO one. However, the quite useful TexMaths extension appears to be broken on 6.1 beta 1 and 2. Trying to edit equations with texmaths and LibO 6.1 beta 2 results in an "Object variable not set." error on line 574 of TexMathsTools oDrawDocCtrl = oDrawDoc.getCurrentController() I have opened an issue on the TexMaths tracker as well: https://sourceforge.net/p/texmaths/bugs/98/ Steps to Reproduce: 1. Open a document with a TexMaths equation in it (tested with a draw document) 2. Select the equation and click the button to open the TexMaths editior 3. Press the "LaTeX" button to reprocess the equation into its svg version. Actual Results: An error dialog is reported. The macro editor opens. Expected Results: The equation svg image is regenerated. Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
I confirm with LibO 6.1.0.0.beta2 The same extension works without a problem on 6.0.4.
bugs about LibreOffice extensions should be send to its authors Status -> RESOLVED MOVED
Agreed, bug opened here was mainly to help users find a pointer to https://sourceforge.net/p/texmaths/bugs/98/
Some more insight on the issue. Texmaths creates images (either as png or svg) of rendered equations. The issue seems to be restricted to cases where texmaths is asked to create an svg image from a latex equation. There is no issue with the png format. This makes me suspect that the change in the svg filters reported in the LibO 6.1 release notes "Replaced existing SVGFilter using SVGIO" ends up breaking extensions. Was the change meant to break some interfaces that extensions relied upon? If so, this should probably be documented. Reopened and changed the bug title accordingly.
I do confirm the problem started after https://cgit.freedesktop.org/libreoffice/core/commit/?id=3ca7be09834a26fbd1c371deabd7a58111092676 author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-10 17:49:19 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-18 20:11:35 +0200 commit 3ca7be09834a26fbd1c371deabd7a58111092676 (patch) tree 560c1ee287e529b8879bbc2375b5a48f87c65a51 parent c845135b7b605257b5c94b382d88627282cb05a3 (diff) Replace SVGFilter using SVGIO Adding Cc: to Armin Le Grand
This is the problematic part of TeXMaths and also a minimal macro that can be used as a testcase reproducing the bug: <code> Sub Main ' Import the graphic from URL into a new draw document Dim arg1(0) as New com.sun.star.beans.PropertyValue Dim oDrawDoc as Variant, oDrawDocCtrl as Variant arg1(0).Name = "Hidden" arg1(0).Value = TRUE oDrawDoc = StarDesktop.loadComponentFromURL("file:///home/bubli/Pictures/bubli.svg", "_blank", 0, arg1() ) oDrawDocCtrl = oDrawDoc.getCurrentController End Sub </code> oDrawDoc is empty b/c loadComponentFromURL fails with *any* SVG file. However, comment out 'Hidden' attribute and it magically starts to work again.
Created attachment 143347 [details] A file generated by TeXMaths I've attached a small .svg generated by TeXMaths for completeness. I fished it out of some temp folder, but it's not really relevant WHICH svg file I'm trying to open via the macro above, it works for none of them
@Bubli: Thanks for the Data and annotations. Grepping, debugging... Ah, fails due to !xStatus.is() in SVGFilter::filter. Compared with libreofficve-6-0 version (SVGFilter::implImport). There, xStatus is used and set, but seems not required. Good catch! Have to change that...
See https://gerrit.libreoffice.org/#/c/57062/
Thanks for the extra quick action! Will it be possible to try to push it to one of the next release candidates of 6.1.0, to assure that TeXMaths (and possibly other extensions) work on LibO 6.1 from day one?
(In reply to sergio.callegari from comment #10) > Will it be possible to try to push it to one of the next release candidates > of 6.1.0, to assure that TeXMaths (and possibly other extensions) work on > LibO 6.1 from day one? First will go to master, you can test that with a nightly build then. Backport to 6-1 makes sense, too.
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a27688e0b54e124ab533b9670da76ef9dc455d2 tdf#118254 Do not rely on XStatusIndicator for SVG import It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Can you back port to 6.1?
Another report on their TexMaths tracker: https://sourceforge.net/p/texmaths/bugs/101/
It has been already cherry-picked to 6-1: https://gerrit.libreoffice.org/#/c/57097/ I'm sure if will land in 6-1 within a few days. The issue will be fixed for 6.1 RC2, don't worry
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ca92f22bb4bc1931cb1237a2348682b83c00e78&h=libreoffice-6-1 tdf#118254 Do not rely on XStatusIndicator for SVG import It will be available in 6.1.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.2.0.0.alpha0+ Build ID: 67f3063b7c334d4d5c59132d90b938671aad09f0 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Armin, Thanks for fixing this!!
Unfortunately there are still regressions in the management of svg files that block the use of the Texmaths extension (and possibly others) with LibO 6.1. Specifically, when inserting svg equation images with LibO 6.1 their scaling is incorrect (much smaller than they should be). I'm opening a new report for this later issue.