[Lazarus] Metafile support

[Alexander Klenin]

On Thu, Apr 7, 2011 at 23:55, Felipe Monteiro de Carvalho
<felipemonteiro.carvalho at 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.carvalho at 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.carvalho at 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.carvalho at gmail.com> wrote:
> On Thu, Apr 7, 2011 at 1:46 PM, Felipe Monteiro de Carvalho
> <felipemonteiro.carvalho at 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