Am 20.09.2017 um 20:22 schrieb Scott Kostyshak <skost...@lyx.org>: > > On Mon, Sep 18, 2017 at 10:21:46AM +0200, Stephan Witt wrote: >> Am 18.09.2017 um 05:55 schrieb Scott Kostyshak <skost...@lyx.org>: >>> >>> On Sun, Sep 17, 2017 at 06:24:46PM +0200, Stephan Witt wrote: >>> >>>>> Den 13. sep. 2017 03:29, skrev Scott Kostyshak: >>>>>> It actually amazes me how few people care about including bitmaps >>>> >>>> I certainly care too. >>> >>> Rereading the email I sent, it could easily be interpreted as though I >>> was implying that you did not care. To be clear, I'm sure you do care (I >>> actually assumed that everyone on this list would care, and I guess that >>> is why I was so sloppy with my poor choice of words); and I appreciate >>> your work on finding the best practical solution for LyX users, given >>> all of the constraints. I agree that giving an error on the first >>> impression is not cool at all. >>> >>> Scott >> >> Hi Scott, >> >> I'm always amazed about your marvelous words. Thank you. >> >> IMO, the current situation on Mac is as follows: >> >> The user starting LyX for the first time gets splash.lyx presented. >> This file, the tutorial and the user guide cannot be printed because >> of the included SVGZ icons. >> >> With the patch (I’ve posted recently) this can be solved by the >> installation of Inkscape. Therefore an advise in splash.lyx should >> be given. > > Agreed. I would say we would then put the advice in all of the help > files where it is necessary. > >> Pavel said the installation of the ImageMagick tools would improve >> the LyX usability significantly. This one isn’t solved yet. But I’m >> not sure how important the presence of ImageMagick for the average >> user is. I think that one can live without it. >> >> Unfortunately I couldn’t get an usable answer how to convert included >> SVG images via the PNG route to printable output. This is not possible >> because of LyX calling convertDefault.py regardless of the presence >> of the convert utility. If I include a PNG image manually converted >> beforehand I get a printable output. > > Thanks for the summary of the situation, Stephan. > > The current situation is not worse than 2.2.x, right? In other words, > there is no regression with regards to 2.2.x, but an argument could be > made that there is a regression (from the user perspective) with respect > to before we changed to SVG files. Did I get that correct?
Yes, the problem is present since the change from PNG icons to SVG icons. > Assuming that there is no regression with respect to 2.2.x, I think we > should start thinking of temporary fixes, like the one you suggest above > of putting a note in the help files. I'm not sure that coming up with a > better fix is worth the extra time and the risk that it will break > something else, considering we are thinking of rc1. I have seen several > user reports and confusion about the issue, and I would expect several > more even with our addition of a note, but I'm leaning towards just > accepting that for 2.3.0. What do you think? I’m in favor of a working SVG to PNG conversion for systems without a SVG to PDF or EPS converter. Ideally for inset-info only and for SVG graphic insets presenting an error message. But this is too complex for 2.3.0, IMO. So I’d put my patch in and let some nice guys change the splash files. Shouldn’t the Linux packagers made aware of the dependency of LyX on Inkscape? (Yes, I know, on Linux it would work without it by using convert. But this isn’t good - an error should be raised on Linux too. :) > I think that after 2.3.0 is out, we should prioritize fixing the root > issue. It is important that users be able to compile help files > out-of-the-box. In some sense, this was already not the case because we > ask users to install certain LaTeX packages to compile the help files, > but additionally asking them to install a program (especially Inkscape, > which I imagine is heavy) does not seem like an acceptable long-run > solution in my opinion. Yes, I think so too. > By the way, the following is a useful thread: > > > https://tex.stackexchange.com/questions/2099/how-to-include-svg-diagrams-in-latex The solutions to output SVG to printable files with LaTeX are using the „evil“ shell escape, BTW. > One of the answers > > https://tex.stackexchange.com/a/2150/12212 > > suggests a program called SVG Rasterizer, which apparently can convert > to PDF (I believe without rasterizing, as e.g. ImageMagick would) [1], > is open source under the Apache License [2], is under active development > [3], and has a detailed list of exactly which features of SVG are > supported [4]. I read the text you’ve referred to with [1]. Of course I don’t know more but if a tool can output PNG, JPEG, TIFF and PDF I’d bet the PDF is a container for a rastered image only. > But I don't imagine we would want to depend on a Java app, especially > since Mac does not ship anymore with the JRE [5]. I was surprised to see > that in configure we do check for a Java interpreter (see e.g. > 81633176), and for certain .jar binaries (e.g. 'htmltolatex.jar'). But I > suppose that checking for system-installed jar files and shipping a jar > file are different things. Nonetheless, since I know nothing about Java, > I leave my above investigation on the 0.1% chance it is useful. The additional dependency would be bad and should better be avoided. Stephan > > I would appreciate other opinions on what to do, both short-run (2.3.0) > and long-run. > > Scott > > > [1] > From what I understand by the text "despite its name" in the following > link, it implies that the conversion would be a vector conversion, i.e., > that the resulting PDF would not be rasterized, as e.g. converting with > ImageMagick. > https://xmlgraphics.apache.org/batik/tools/rasterizer.html > > [2] > https://xmlgraphics.apache.org/batik/license.html > > [3] > http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/ > > [4] > https://xmlgraphics.apache.org/batik/status.html > > [5] > https://apple.stackexchange.com/questions/102466/does-java-come-pre-installed-on-mac-os-x-10-7-10-8-and-beyond
