Hello,

I and another worker have developed a vector graphics library for Free Pascal and I am thinking about making it modifyed-LGPL and adding to the lazarus-ccr repository, like fpspreadsheet. So I was wondering, anyone interrested in it?

At the moment it supports only reading PDF and only writing GCode for a CNC machine I am developing and also only lines and polylines (I will be adding curves in the next months), but the main structure is done and it is extensible for more formats and more geometrical figures and it's properties.

Here is the kind of code that you can write with it:

      Vec := TvVectorialDocument.Create;
      try
        Vec.ReadFromFile(dialogoAbrir.FileName, vfPDF);
        Vec.WriteToStrings(memoCodigo.Lines, vfGCodeAvisoCNCPrototipoV5);
      finally
        Vec.Free;
      end;

Just 1 command to read a PDF, then the information is in the class and just another command to save the output to a file, or a TStrings or a TStream.

Formats are added by adding units to the uses clause, so only necessary code is linked. Upon initialization they add themselves to a list of formats in the fpvectorial unit.

bye,

2009/5/26 Felipe Monteiro de Carvalho :

this sounds great, felipe, congratulations. simple pdf writing would also be a great feature.

henry

Felipe Monteiro de Carvalho wrote

Hello, I and another worker have developed a vector graphics library for

Free

Pascal and I am thinking about making it modifyed-LGPL and adding

to

the lazarus-ccr repository, like fpspreadsheet. So I was wondering, anyone interrested in it? At the moment it supports only reading PDF and only writing GCode

for

vfGCodeAvisoCNCPrototipoV5);

and

just another command to save the output to a file, or a TStrings or

a

TStream. Formats are added by adding units to the uses clause, so only necessary code is linked. Upon initialization they add themselves to

a

list of formats in the fpvectorial unit. bye,

Count me as interested as well :) - I also have a CNC machine, and looking to be able to use pdf/svg from pascal - Well done

Shouldn't it be part of FPC's canvas/image support ?

Or does it depend on the LCL ? I imagine only actual drawing routines depend on the LCL, in which case it can be split in a GUI-independent part (reading/writing files) and a GUI dependent part, such as drawing code.

Michael.

Michael Van Canneyt wrote

Shouldn't it be part of FPC's canvas/image support ?

But FCL canvas/image is for raster images. I don't see how they would correctly describe vector images.

PDF can hold text, raster images and vector images. For this library I am ignoring the text and the raster image and using only the vectors part.

Or does it depend on the LCL ?

No, I am talking about non-visual support for the formats.

There could be routines to draw the images into a canvas, but I haven't developed any yet.

All correct, and currently we have support in FPC for raster images. My proposal is to add your code to FPC so we also support vector graphics: FCL-image seems like the appropriate place for this.

> Or does it depend on the LCL ? No, I am talking about non-visual support for the formats.

Excellent, that means your design starts from good principles :-)

Michael.

Michael Van Canneyt wrote

All correct, and currently we have support in FPC for raster images. My proposal is to add your code to FPC so we also support vector graphics: FCL-image seems like the appropriate place for this.

I see, but are you proposing to add my units to fcl-image as they are (which would mean separate classes for raster images and vector images) or try to have a multi-concept class? Just trying to understand, I would prefer to keep things separate.

Of course, separate classes; I don't think it is very realistic to have a single concept for both.

What could be added later on is a class that does the drawing of the vector graphics on a TFPCustomCanvas, and can then be used to create a bitmap with the TFPBitmapCanvas descendent or on a window - since the LCL TCanvas is a descendent of TFPCustomCanvas anyway.

Michael.

Ok, so here is the file as it is at the moment for review so that we can stablish a stable API (and I would like it really stable after that).

Take into consideration that it's work in progress.

The place that I see that could be discussed is:

    function  GetPolyline(ANum: Cardinal): PPolyline;

Could be changed to return TPolyline and raise an exception if out of bounts instead of returning nil in this case. An property could also be added for this getter.

There is also the question of the measure unit, I am using milimeters at the moment.

For the rest I guess it's just a question of adding more stuff.

Better ignore this file, my latest fpvectorial works with the concept of paths which support mixing lines and bezier curves in the same path.

Hello,

I added fpvectorial under packages/fpvectorial and started a page for it on the wiki

I still didn't make makefiles because they really confuse me ...

bye,

Felipe Monteiro de Carvalho wrote

I still didn't make makefiles because they really confuse me ...

Isn't it time to switch to the new build system any way? 'fpmake.pas' style?

Just curious, when is the switchover going to happen? From Makefiles to fpmake.pas style?

Regards,
- Graeme -

In our previous episode, Felipe Monteiro de Carvalho said:

I'll have a look.

Felipe Monteiro de Carvalho wrote

I still didn't make makefiles because they really confuse me ...

You don't have to write a makefile, only a makefile.fpc, and those are dead simple. Just copy paszlib/Makefile.fpc and change the name, required packages (if any, otherwise just delete it) and unit/ implicitunits.

Jonas

In our previous episode, Felipe Monteiro de Carvalho said:

I added fpvectorial under packages/fpvectorial and started a page for it on the wiki I still didn't make makefiles because they really confuse me ...

- There are writeln's in several places. This will break Windows GUI (Darwin too?) programs, and look sloppy on other systems.
- There are lazarus packages there. It should go to Lazarus I think, since there is no good way to install it in Lazarus from a FPC release.

Marco van de Voort wrote

- There are writeln's in several places. This will break Windows GUI (Darwin too?)

On Mac OS X writeln's from GUI apps simply go into the system and console logs (or to the console itself, if you start a gui app from the command line window).

Jonas

Marco van de Voort wrote

- There are writeln's in several places. This will break Windows GUI (Darwin  too?) programs, and look sloppy on other systems.

I isolated them in ifdefs

- There are lazarus packages there. It should go to Lazarus I think, since   there is no good way to install it in Lazarus from a FPC release.

I removed the lazarus files, they aren't thing is about the dependencies, a single unit, "fpvtocanvas.pas" depends on fp-image, so the whole fpvectorial needs to depend on it too as a build requisite, but nothing from fp-image is used except in this unit, which has no other unit depending on it.

In our previous episode, Felipe Monteiro de Carvalho said:

Yes. Our dependancies have package granularity. This avoids too much micro-managing dependancies (which means effectively they are always out of date). As long as it doesn't pull in unnecessary external dependancies, that is not a problem.

Note that this is just a bunch of barren units. To make a decent package, this needs to be done:

- Add to all units a decent copyright header WITH a description that is more descriptive than the unit name.
- Add an entry to the "packages list" lemma in the wiki
- examples, tests.