Forum > FPvectorial
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:
--- Quote from: Blestan on August 04, 2017, 07:15:14 am ---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
--- End quote ---
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:
--- Quote from: Blestan on August 04, 2017, 07:15:14 am ---fpvectorial is ina very early and raw stage....
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page