I went back to see what changes I made to my local checkout. In the end, I gave up working on the issue.
The subpixel thing worked, but it didn't look any better.
I tried to at least try subpixel rendering of the glyph bitmap to see if it makes things look better. Due to this, the font can sometimes look like it has weird kerning. The bitmap is cached so wherever the glyph of the same style and size is needed, the same thing is drawn. The default Roman font is not TTF and cannot be rendered by FreeType, so TeXmacs has its own bitmap renderer for TFM fonts.īasically, a glyph is rendered monochrome at a large size and then scaled down to the needed size with 8 color grayscale, IIRC. The font doesn't look as crisp as what you'd see in other ClearType-enabled applications.Įarlier this year, I checkout out the SVN repository to see what's going with the renderer. It is hands down the most pleasant to use for that purpose.īut I still get distracted by this one issue that bugged me since I first tried it 15 years ago: the anti-aliasing quality. TeXmacs is one of those apps that I reinstall from time to time when I want to scribble some math notes and find the split screen setup of most LaTeX editors or Markdown with preview too distracting. Again not blaming you or the particular TeXmacs devs working on import, this situation is a fatality of how LaTeX works. There are also a bunch of macros that are shown as raw visible commands in TeXmacs and I don't know what to do with those (but that's certainly something I could learn to manage). To answer your other comment, this paper of mine has many problems when importing in TeXmacs: the title is not aligned correctly, the algorithms are messed up, the figures don't have the correct sizes, and one of the figures which is exported from Inkscape is not even imported at all. This would be of course significantly simplificated if import followed by export (and the reverse) was the identity function, which would technically allow TeXmacs to directly edit LaTeX documents without having to rewrite them entirely, but I don't believe that to be the case and again I don't see how it could be possible. In particular I rely heavily on git to manage document history and to view diffs from my co-authors, and having to manage a document that exists in two languages simultaneously would add significant complexity to a workflow that I'm already barely able to make my co-authors follow. To be clear the problem is not TeXmacs, but the fact that in a team most people work in LaTeX and having to constantly convert from one another would be impractical. I'm sorry you interpreted my comment in that way, I did not mean to say that TeXmacs had shortcomings in the way it imports LaTeX, in fact I do believe it does its best given the constraints it faces, but as you justly said the task is impossible in the general case given LaTeX's Turing completeness. Hey, thanks for sharing your perspective. But if you carefully reread it, then you will understand that it isn't. Therefore, my reply might sound aggressive. Now it is plausable that the author is not even aware of the implicit bias of the terms 'incompatible with LaTeX' and 'partial converter'. I think that this is a misrepresentation. The way the comment is stated, it suggests that TeXmacs is not good enough. Secondly: who is to blame for this incompatibility? TeX/LaTeX was designed to have a Turing complete grammar, which makes it impossible to write 100% reliable converters. Now one has to be fair when making this kind of statements.įirst of all: how 'big' is this incompatibility? I think that it is not that big at all and roughly as big as when you use a new style package with LaTeX or when trying to recompile a 25 year old LaTeX file. I understand from the original comment that the author likes to use TeXmacs, but that (s)he thinks that the proclaimed incompatibility with LaTeX is too big a drawback for more than occasional use. It is not my intention to sound aggressive, but just to get things straight.
0 kommentar(er)
