I have been using an appimage of Texmacs 2.1.1, but recently switched to version 2.1.2 from this link: specifically, texmacs-2.1.2.svn13867+extras-0-x86_64.pkg.tar.zst.
I’ve noticed that figures look blurry now.
Using the appimage (v 2.1.1):
Using the version from the link:
What’s going on?
Does this happen with all graphics formats?
I tried a png image; that displayed fine (no blur). It seems that pdf images (vector graphics) are the ones affected.
Better to report it in the texmacs-user mailing list, maybe TeXmacs has been build without Ghostscript, or something in this direction. Alternative explanation: PDF files are externally converted to PNG with the wrong resolution. This should not happen. What is the result of exporting to PDF the document?
Exporting to pdf is fine. It is blurry during editing. As I mentioned, this was not the case in version 2.1.1 (at least, the appimage I was using).
I don’t see this on the my build of the most recent SVN. Could you try to
Tools->Debugging tool
Debug->convert
For me pdf gets converted using gs. Perhaps Ghostscript is missing on your system or TeXmacs can’t find it.
The link is a build of mine, and I guess the Appimage was too. In the 2.1.2 builds, I applied http://savannah.gnu.org/patch/?10175 which modifies a bit image handling and that could be the (unexpected) cause of what you see. Specifically, external image converters called from scheme were modified, and details may depend on the converters TeXmacs finds on your machine – I did not observe your issue during my tests, but I cannot test all configurations. In any case, running with debug-convert as Jeroen suggests will probably explain why the images look different.
Note that there are also Appimages for 2.1.2 (two of them actually, a qt4 and a qt5 version, see https://build.opensuse.org/package/show/home:slowphil:texmacs-devel/texmacs). You could perhaps check if they have the same issue as the arch package? (I expect they do)
Thanks for writing this nice patch, @pjoyez! I have applied your patch to the latest svn and I get clear images. debug-convert tells me gs is being used. It would good to know what output @hamorabi is getting.
I do get an error from the line (test-version-num "inkscape -V" "Inkscape " 0.92). Executing inkscape -v returns 1.2 (dc2aedaf03, 2022-05-15), which doesn’t work with the function.
Perhaps something like this could work?
(define (all-ints? l)
(if (null? l) #t
(and-with f (string->number (car l))
(if (integer? f) (all-ints? (cdr l)) #f))))
(define (test-version-num cmd key minv1 minv2)
(with a (eval-system cmd)
(if (string-null? a)
#f
(with st (if (string-null? key)
0 (string-search-forwards key 0 a))
(if (== st -1)
#f
(let*
((a (string-split (substring a st) #\space))
(a (map (lambda s (string-split (car s) #\.)) a))
(a (filter all-ints? a))
(v1 (string->number (first (car a))))
(v2 (string->number (second (car a)))))
(or (> v1 minv1)
(and (== v1 minv1) (>= v2 minv2)))))))))Thank you Jeroen, for pointing to the fragility of the version checking and for your proposed fix. I’ll update the patch to make it work with Inkscape 1.2.
Sorry for reviving an old thread. I am install texmacs from the aur. It seems that texmacs is using qt instead of ghostscript to convert the pdf into png. I have ghostscript installed.
TeXmacs] debug-convert, image_to_png ... using qt
TeXmacs] debug-convert, qt_convert_image /home/hamorabi/sample.pdf -> /home/hamorabi/.TeXmacs/system/tmp/181386/tmp_63472292.png
It’s pretty strange the aur texmacs build uses Qt to convert pdf to png, but it provides a partial explanation: In TeXmacs code, conversion through Qt is attempted before gs conversion is even tried; so it means on that system, Qt is configured (and declares itself able) to render pdfs. I have not seen this elsewhere yet, and the bluriness you get indicates Qt sucks at this conversion… For a quick fix, you can disable this conversion by Qt for pdf files, or attempt the gs conversion before the Qt one (around line 500 in image_files.cpp). If you can get your hands on Qt4 libraries in arch, you can also revert to a Qt4 build.
For the AppImages v 2.1.1 of the first post and v 2.1.2 in the other thread, the embedded Qt library does not support pdf rendering, so that it should call gs and the result should be crisp. At least that’s what happens when I try.
I originally thought you had tested AppImage 2.1.2 and that it also gave blurry images for pdfs on your system, but now I believe not, so I edited this post. If it indeed produces blurry images, please share the debug output of the “good AppImage” and the “bad AppImage” when converting the image. If you do this, please turn on both the debug-convert and the debug-io switches.
Sorry to revive this thread again. It would be nice if someone can offer a solution.
Well, someone already offered solutions in this thread, actually.
And there is a much easier solution : the AppImages display crisp curves, as you already noted in your first post.
Isn’t it nice?
I’m not versed in C++ to know exactly what to do.
The latest version the AppImage does indeed produce crisp images, but typing is very sluggish. Texmacs becomes unusable in beamer or large documents. I think I have already posted several videos about it.
@pjoyez would be crucial to understand why the AppImage “feels” differently than the version on the website. Does somebody else experience the same differences?
@hamorabi, you did it again, switching to another issue and referring to posts in unrelated threads. Please don’t do this; it makes discussions confusing and hard to follow, even with good will. Indeed, the way you formulated your last post, @mgubi understood that the AppImage has a specific sluggishness problem and he asks me why…
Let’s put things straight:
An AppImage is merely a Linux binary packaged in an image file. After the image decompression at startup (a couple of seconds at most) it runs the same code just as fast as any other Linux build (of the same version, of course). I have never seen any difference in performance, and no one ever reported any to me.
There are known situations (and corresponding bug reports) where TeXmacs gets slow, but that has nothing to do with using an AppImage or not. Please do not confuse people about that.
Regarding your perceived general sluggishness of TeXmacs 2.1.2, you have reported it often; we are aware of your dissatisfaction. Constantly harping on this complaint in different threads is not helpful in this forum, quite the contrary, you see. Either live with it, stick to the former version, or find ways to constructively help the volunteer developers improve the situation.
Coming back to the thread’s subject, using any version of the AppImage solves the issue, with no tradeoff related to being an AppImage. The issue you reported has been diagnosed and solutions proposed; perhaps you could mark that thread as [solved]. I would appreciate it.
I agree that mixing issues creates chaos. However, as far as I understand, here @hamorabi is noting that the proposed solution has another defect that makes it difficult to apply.
On the other hand there is a suspicion that something has escaped @hamorabi when observing the sluggish behaviour of the AppImage, because, as @pjoyez says, the application being the same other builds, it must behave in the same way. If none else has complained about TeXmacs 2.1.2 being sluggish, then the sluggishness cannot depend on the application being distributed as an AppImage.
My reason for constantly harping on this issue is because I really like using Texmacs but these issues are taking away from the awesome experience I get when taking notes. In any case, I’ll refrain from posting on this forum anymore.
You are taking it too hard 
I would say, rather, let us see what we can do to fix everything.
@pjoyez made a sensible remark when he said that mixing subjects creates chaos, now we need only to keep things in order and we will be in the right position to fix everything 
It is partly my fault believing the issue was present only in Appimages. As for the sluggishness personally I use TeXmacs everyday (indeed apart from the webbrowser and the mail client is the only other program I use regularly) and I didn’t experienced this. Would be useful to refer to the thread where the issue is discussed so that we can continue to chat about it there. @pjoyez sorry I was not meaning that AppImages were at fault! Actually I always suggest to my Linux friends to use your Appimage which is vastly more convenient than the standard approach, especially when the used do not have administration rights on the machine (as it happens for example in my University)