The 1.25 release has a number of miscellaneous fixes. The most visible change is the use of custom cursors for most of the tools. Hopefully this will be more helpful than annoying.
The most important change, though, is in the SVG exporter. For a long time I've held out hope that more applications would not support proper handling of embedded fonts, which really is one of the really good calls when the SVG spec was put together. There are basically three types of SVG-enabled applications, as far as I'm concerned: (1) good quality and complete (e.g. Batik, Inkscape, Opera), which means alpha blending and use of embedded fonts; (2) good quality but incomplete (e.g. Firefox, Qt[?], libsvg[?]), which means the line-graphics look great but fonts are incomplete to the point of being useless; and (3) those which look awful, i.e. no alpha blending, which is not an option in today's age... (naming no names here).
Anyway, I've been holding out for a few more renderers to move themselves into category #1, but it doesn't seem to be happening. The really weird thing is that the Firefox developers claim that embedded font support is really hard, even though the way it is encoded is _identical_ to normal curved path rendering... the syntax is even the same. I'm sure hooking up with the native platform font rendering is hard, but they already have the technology to do it really well by another means, which has to be better than what they're doing now. I tested this by adding a feature in SketchEl's SVG output which invokes each of the characters as a link to a predefined path instead of text, and guess what... it looks just great!
So I decided to make this the default output. The semantic meaning of text in a molecule diagram is pretty limited anyway, and practical compatibility should go from about 25% to >50%.
Inspired by the success of this compromise, I decided to embark on an exporter for ODG (OpenDocument Graphics). Now, I knew that this format is only really supported by OpenOffice, which has a graphical rendering model that is stuck in the 1980's, so all its vector art is thoroughly revolting when displayed on the screen, but at least when printed or exported to PDF, it may get re-rendered nicely. And hey, ODG is a well thought-out specification which will one day be widely implemented well by many programs, right?
Not really. It seems that everyone else backs SVG for vector graphics, and rightly so. ODG is a lot more contrived than one might expect, even if it is not as bad as OOXML, but it has some really obvious things missing, e.g. lines always have squared endpoints... no way to make them rounded. Joins can be rounded, but not edges. This is actually a serious problem for molecule rendering... it means I can't use lines at all, I have to draw the outlines of the lines as splined polygons! Hard to imagine how this deficiency slipped through the cracks.
I didn't bother even contemplating that text might work, and went straight for the traced outlines for glyphs. Seems OK, but there's a serious problem: it seems that OpenOffice Draw's graphics primitives are rounding the floating point positions to a rather coarse grid, instead of the fine grid which I was counting on, which means that its rendering of the exported graphics is even worse than one might expect for lack of sub-pixel rendering, but worse yet even still, it passes off the rounding when it exports the graphics. So even when you print or make a PDF of an ODG file, it looks bad. Smooth, certainly, but bad.
Long story short... SketchEl has ODG output, which I think is fully compliant, but there is only one program which uses it, and it doesn't work. Maybe in a few years, things will change.
(If any of this rant is factually incorrect, I would very much like to hear about it!)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.