Lazarus
Programming => Packages and Libraries => FPvectorial => Topic started by: PaulANormanNZ on August 04, 2017, 04:09:44 am
-
Hi,
Just a quick question - been looking through the examples for FPvectorial, and wondered please if there is any code for loading a standard PostSctipt (not EPS) and 'rendering out' a Bitmap or stream in memory to load in a TPicture or something...
I'm trying to avoid writing and reading from Disk.
I need previews for PostScript files, and have looked at GhostScript from a shell, or DLL approach, but as .ps files can be quite large, everything is looking most likely to be a bit slow and wondered if FPvectorial could give me the first page of a PostScript file to show as a Bitmap or in other component at all please?
RELATED (would become another thread I suppose): Is it conceivable to run Tprocess or something in memory and get the filestream from GhostScript back into a bitmap via a MemorytStream? I saw another posting but it seemed to resort to loading from disk - which is a time problem again. ( http://forum.lazarus.freepascal.org/index.php/topic,31686.msg205535.html#msg205535 )
I thought though that something done in FPvectorial would be more native to FreePascal and so possibly faster?
Paul
-
hi eps and postscript files are 90% equal and extremely complex data formats.... it is impossible to write an ps interpreter for ps/eps preview... the format is language and needs a proper runtime to execute.. so, buy a faster disk and cpu and use ghostscript... even imagemagic relies on gs ...
fpvectorial is ina very early and raw stage.... supporting partialy some formats just to manipulate data.its out of question to do some rendering with it the next 30-40 years ;).
please for ps/eps/pdf stick to adobe print engine/ aladin ghostscript/ harlequin ps rip
-
hi eps and postscript files are 90% equal and extremely complex data formats.... it is impossible to write an ps interpreter for ps/eps preview... the format is language and needs a proper runtime to execute.. so, buy a faster disk and cpu and use ghostscript... even imagemagic relies on gs ...
fpvectorial is ina very early and raw stage.... supporting partialy some formats just to manipulate data.its out of question to do some rendering with it the next 30-40 years ;).
please for ps/eps/pdf stick to adobe print engine/ aladin ghostscript/ harlequin ps rip
What are you talking about?
I wrote fpvectorial so I can say that the EPS drawer is the best drawer I've written, because the format is relatively easy to implement, being simply a programming language.
SVG and HTML are real nightmares, extremely complex and far harder to implement in comparison, because they support so many gradients, transformation matrixes, etc.
-
fpvectorial is ina very early and raw stage....
That's simply not true. EPS is feature complete. Other formats are in usable (may or may not be feature complete) and in a stable state.
Felipe does a great job.
-
as as said eps is 90% ps and the devil is in the details
and eps is. not ps but may be fpvectorial handles ps and. eps both
the original post is for ps
sorry for my iignorance:
can you point me with simple links to:
1: an fpvectorial for an equvalent of ps2ps
2: font rendering code of ttf an pbf/ psf fonts glif and here is the default forder for .psf ttf fonts files.
3: patern filll with cliping regions on deviceN bitmaps
4: color managment system code for cmyk 1bit biitmap rendering to fogra39 profile and where are the other color profiles stored?
5: handling color separations of rgb to ciellab color space
6: grapient fill by @proc with stack push / restore
7: rendering of device indepentent color space
8: color trapping and overprinting on lets say deviveN with spot colors + cmyk
9: OPI handling in fpvectorial
10: simple rendering of ps to bitmmap with XObjects proc and spot colors mapping for layered tifs with alpha chanels?
11. handling of registration color gradients
12. 1bit rendering for euclidian, eleptical and stohastic screening with black dot compensation and under color removal
13. memory limits for gradient rendering on device independent bitmaps
14. handling different stoke origins and end caps
for such a complete and mature implementation it will be an easy task to pin point me exact lines in code :)³
thanks in advance
ps :
for all who will continue the discution on ps please give some hints on the following simple newbie code before arguing with me :
gsave
newpath
0 0 moveto
(X) false charpath flattenpath pathbbox
grestore
how many values on the stack after this code?
cheers
-
Hi,
Thank you for the replies.
I was asking about this, as the page for FPvectorial does list links for the PostScript format, so I was hoping that perhaps the EPS engine may help.( http://wiki.freepascal.org/fpvectorial#PostScript )
I have to openly agree that Felipe has done a major job already on all this of great merit - seriously! I have worked with the Corel .cdr format in the deep past and it does take a lot of work to do this stuff. Inkscape have lifted up code to be able to comprehensively import up to CorelDraw 14 now, https://inkscape.org/en/
For .cdr I wonder if there are any units there worth translating to FreePascal?
Blestan those are good questions, I was wondering if some of that would already be in the EPS units?
However I do think that: so, buy a faster disk and cpu and use ghostscript...
is extraordinary guidance for OpenSource developers - it seems to me more like something Microsoft would say %)
I don't think I could, or should, even suggest that to Users! Makes our FreePascal sound lame!
So just to clear things up for me please, from the discussion so far ... generally it seems we are not yet in a position to do PostScript canvas rendering in Lazarus with FPvectorial for now?
Thanks,
paul
-
Ghostscript is an interpreter for PostScript™ and Portable Document Format (PDF) files. It is available both under the GNU GPL Affero license and for commercial licensing from Artifex. It has been under active development for over 20 years and has been ported to many different systems during this time.
so if a product is under gnu licence but not writen in fpc does not make it lame or ms >:D
by the way i have writen a fpc bindings for mupdf because 2-3 years ago no opensource pdf rendering existed ever for fpc
-
P.S: after a brief exam of gs i noted that it can be compiled as library and use the api very very eficiently for you work! i can also help with binding if none exists :)
-
this can be a good starting point
https://github.com/tristan2468/PDFPrint?files=1
take alook if its ok for you and we can fork!
-
Thanks Blestan, but you entirely missed the point I'm afraid.
so if a product is under gnu licence but not writen in fpc does not make it lame or ms
Paul
-
what did i missed ? you wand to avoid running gs from separate process to speedup rendering and i proposed to use gs as dll ... keep in mind that ps rendering is a slow process im dealing witb it from 1993
-
by the way i have writen a fpc bindings for mupdf because 2-3 years ago no opensource pdf rendering existed ever for fpc
That is an excellent piece of work, I use mupdflaz mupdfview component made by Malcolm Poole inspired by your work Blestan - never had a glitch with it thanks.
Paul
-
That's a great idea Blestan.
Is there any way of getting the output back into Lazarus as a TStream of some sort without going via disk at all please?
Or will using the DLL require it going via GS's normal route, to file first?
Paul
what did i missed ? you wand to avoid running gs from separate process to speedup rendering and i proposed to use gs as dll ... keep in mind that ps rendering is a slow process im dealing witb it from 1993
-
what did i missed ? you wand to avoid running gs from separate process to speedup rendering and i proposed to use gs as dll ... keep in mind that ps rendering is a slow process im dealing witb it from 1993
Sorry if there is any misunderstanding - all I meant that if we could have something more natively FreePascal it would be faster and we wouldn't have to recommend upgrading disks and cpu etc. Otherwise we make FreePascal out to be lame - not MS or GS.
Paul
-
i think that gs has a displaay callback so examine this
gsapi_set_display_callback()
this should work
-
the api has run string to ezexute ps code but i think that max buffer size is 64K ... as i told ps is extremely expensive complex and slow to run and render
-
Thanks Blestan,
Getting a preview onto a Lazarus canvas is my focus - but how much time would really be saved trying for a more internal Lazarus path, when the main time overhead from what everyone is saying: is the GS processing portion - so writing bmp/jpeg/png to disk and reading the 'preview' back from disk may not be the time overhang I have envisaged and been trying to avoid?
Doing it all from GS DLL should nonetheless be faster than a Shell call; I can assume?
In the background stuff below, there is a test.exe pilot (incomplete) project that appears to actually render a workable preview of a .ps file in Delphi (found in gsapi_delphi.zip)..
Written by Alessandro Briosi with the
// assistance of Russell Lang it all uses a unit gsimage providing TGsImage which gives us:
DISPLAY_COLORS_GRAY, _RGB, _CMYK
and Colour depths 1, 4, 8, 16
Offers varying DPI and is quite fast already actually. Looking hopeful.
I think its all under an MIT like license, so this may save some time?
---
Found some background stuff in case it saves any one any time...
The Delphi community have some helpful things--
https://stackoverflow.com/questions/20778134/extracting-plain-text-from-postscript-file-via-gsdll32-dll
The Answer there - GhostTools.pas Class file for GSDLL32.DLL has some helpful top level things.
It uses gsapi.pas no longer available via
http://pages.cs.wisc.edu/~ghost/doc/gsapi.htm
and
http://mirror.cs.wisc.edu/pub/mirrors/ghost/contrib/gsapi_delphi.zip
gsapi.pas is findable here though:
http://www.filewatcher.com/m/gsapi_delphi.zip.208923-0.html
And from that bundle specifically this looks helpful:
https://github.com/tristan2468/PDFPrint/blob/master/GhostScript.pas
Some notes here:
http://mseide-msegui-talk.narkive.com/2UJ4ZIAh/ghostscript-api-implementation
Paul
-
Ok,
I imported that trial test.dpr into Lazarus from gsapi_delphi.zip
After the import I only had to REM line 192 in gsimage.pas
// was needed ...
// bm.IgnorePalette:=true;
... I'm not sure whether this needs further research or things are ok as they are now.
Any way it works very well as it is so far.
Certainly adequate for a generalised preview glimpse of PS. Handles pagination and all.
I've attached gasp_delphi.zip there is a readme.txt
Paul
-
good to see that you are advancing !!!
just few more hints from me:
1. try to use as canvas bgrabitap because its very very... as i did for mupdf. it will save alot of drawing time
2. if you want adecuate colors of the preview use litlecms... pascal bindings are perfect.
3. if you render/ saving to a temp file avoid using compressed files like jpg or png this will save alot of decoding time.
4. create please a github repo with all code name it fpc-gs for example i will join
5. create a new theread in the forum under "graphics" section to anounce all gs stuff with others
:)
blestan
-
Thank you for the suggestions blestan, but I don't believe I have the competency to head up a component development for widespread usage.
May whoever is, and who is willing -please feel free to.
Certainly your experience with mupdf would be a really great basis to work from blestan!
Paul