2013/8/30 mathog <mathog@...1176...>:
Sure, but since dropping the libUEMF source files out of inkscape isn't going to be an option until distros start including it, there is no hurry.
OK. For now I'm going to put it in a separate directory, so that it can be easily upgraded from the upstream version. I'll put the symbol font conversion routines in the same directory, since this functionality is closely related to EMF output. I don't know what to do with 'libTERE' yet - I assume you mean the text_reassemble.[hc] files in src/extension/internal.
By the way, it seems you haven't added yourself as an author to the EMF output files which you significantly changed. Can I add your name and e-mail there?
Regards, Krzysztof
I started working on code cleanups in the EMF support, and it looks like there is room for improvement.
1. The code contains many unnecessary C-isms and ad-hoc manipulation on data structures which obscure its meaning. For instance, the functions search_long_fflist and search_short_fflist could be made a lot simpler and faster by using std::map. Implementing linked lists at every point of use is never a good idea.
2. I don't see why Inkscape should completely refuse to start when fontfix.conf is missing. If that's the case, either do not initialize the EMF output extension or use emf_long_fflist that contains only the default record with empty fontname and f1, f2, f3 equal to zero.
3. Every call to emf_append is wrapped in a conditional that calls g_error on failure. If potential errors in emf_append are never recoverable, this assertion-like construct should be put inside the emf_append function itself, to reduce unnecessary duplication of code. Moreover, an error in the output extension should not abort the entire program, and that's exactly what calling g_error does. Just clean up and tell the user that they should report a bug.
4. The Inkscape parts of the work do not follow the Inkscape coding style. Whitespace can be fixed with astyle (I added a suitable astylerc to the tree), but there are also many variable and function names which break the naming conventions and need to be fixed manually.
Regards, Krzysztof
participants (1)
-
Krzysztof Kosiński