PostScript (page 01) for preview display via FPvectorial?

[PaulANormanNZ]

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

[Blestan]

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

[felipemdc]

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.

[Thaddy]

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.

[Blestan]

 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

[PaulANormanNZ]

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

[Blestan]

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 

by the way i have writen a fpc bindings for mupdf because 2-3 years ago no opensource pdf rendering existed ever for fpc

[Blestan]

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 

[Blestan]

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!

[PaulANormanNZ]

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

[Blestan]

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

[PaulANormanNZ]

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

[PaulANormanNZ]

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

[PaulANormanNZ]

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

[Blestan]

i think that gs has a displaay callback so examine this
gsapi_set_display_callback()
this should work