On Thu, Apr 7, 2011 at 23:55, Felipe Monteiro de Carvalho <felipemonteiro.carva...@gmail.com> wrote: > Could you repost your e-mails to the mailling list? It seams that they > came only to me, while they might be useful for the general audience.
Oops, gmail defaults have caught me again. ---------------------------- On Thu, Apr 7, 2011 at 21:41, Felipe Monteiro de Carvalho <felipemonteiro.carva...@gmail.com> wrote: > I think that the best would adding WMF and EMF writer modules to > fpctrunk/packages/fpvectorial That was my first thought too, but after looking at fpvectorial interface I found that it is not currently suitable neither for TAChart nor for WMF. This line in SVG writer illustrates some missing features: style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" >as opposed to using so Windows APIs The code I found does indeed use WinAPI, so it is Windows-specific. However, the upside is that it is relatively simple and possibly more efficient then hand-made implementation. Variants for other platforms may use corresponding libraries, like libwmf I think the difference is similar to LCL vs FPGUI -- "native look and speed" vs "portability and common code". ---------------------------- On Thu, Apr 7, 2011 at 22:46, Felipe Monteiro de Carvalho <felipemonteiro.carva...@gmail.com> wrote: > I'm in the process of implementing fill pattern, fill color, stroke > (aka pen) color and pen width for the DXF reader as well as the > generic data structure. Good. > If you verify the data structures used you > will see that extending them for further capabilities is very easy > because the structure is will designed. That is an excellent goal. Currently, however, there is some space for improvement: 1) Basic reader/writer is based on enum TvVectorialFormat, which does not allow adding new formats. 2) The data structure is very unefficient -- a class for every point in line! Also, usage of linked list makes random access to the structure very slow. 3) There is a separate function in TvVectorialDocument for each entity type, which does not allow adding new entities. > The difference is that the LCL uses libraries which are present anyway > in the user system, like Gtk and Qt. > > libwmf seams like an unwanted external dependency to me. It doesn't > come preinstalled in my Linux, for example. Installing it in my > MacBook would probably be a nightmare. Yes, but this is true for half of the packages present in FPC, see recent freetype problems for example. So I do not think one more dependency is a serious problem. ---------------------------- On Thu, Apr 7, 2011 at 22:57, Felipe Monteiro de Carvalho <felipemonteiro.carva...@gmail.com> wrote: > On Thu, Apr 7, 2011 at 1:46 PM, Felipe Monteiro de Carvalho > <felipemonteiro.carva...@gmail.com> wrote: > If you really dont want to implement a WMF writer, then I suggest that > you use libwmf to implement a writer backend for fpvectorial. This way > when someone implements a native WMF writer TAChart can be changed > with a single line of code to use the new native writer. Generally, I plan to implement fpvectorial back-end as soon as fpvectorial will have required features. Exporting TAChart to DXF would be cool, even if not useful ;-) After taking a closer look at libwmf, I noticed that it is mostly for _reading_ wmf, so I am afraid a native writer is the only way for fpvectorial. -- Alexander S. Klenin -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus