🚀 go-pugleaf

As I understand it, several programs including some versions of
FreeHand write an EPS containing the original Freehand file embedded.
So if you reopen a Freehand EPS you aren't parsing the EPS content at
all, just going straight to the embedded Freehand file.

Aandi Inston

In article <2cd0da75.-1@webx.la2eafNXanI>,
 Vahan_Babakhanian@adobeforums.com wrote:

> 1.
> Freehand MX
> I am doing the following steps:
> create simple "empty" object with only 1 text line
> let's say "TEST 1"
> export as t1.eps
> close file in FH MX
> open eps file in Text editor
> edit text line to "TEST 2"
> save
> open t1.eps file in FH MX
> it brings old text line "TEST 1" ignoring the results of recent editing
> 
> why?
> 
I believe that Aandi has posted the correct answer; while I haven't used 
the more recent versions of FreeHand myself, I'm pretty certain that the 
application still doesn't include any kind of PostScript parser. AFAIK a 
'native' FHMX database uses some variety of XML to describe the objects 
and pages in a document. In earlier versions the "Editable EPS" format 
has indeed comprised an EPSF page description with the preview and 
native code appended (or maybe prepended) to it. For the same reason an 
altered EPSF that had originally been saved with a PICT, TIFF, or WMF 
preview will look unchanged on-screen e.g. in a layout program, but when 
printed or otherwise interpreted the changes should be apparent.

But you don't say what happens when you print the altered EPS, or open 
it in Illustrator or the like -- I would expect your change to show up 
there, because in these circumstances the native FH data will be ignored 
but the PostScript will be executed, the converse of the scenario you 
describe.

> 2.
> I need to change some Text lines in given EPS file (created either by FH 8, 
> 10, MX or by Illustrator) via the program/script.
> I assume that if I will simply replace old text value with new and save the 
> file it should work. It doesn't.
> 
> why?
> 
See above. But I would expect an Illustrator v8 or earlier file to show 
the effects of altered PS code, because its native format was in fact a 
'dialect' of PS. I'm not sure whether EPSFs saved out of AI v9 and later 
contain native code, but if they do it will be in a 'dialect' of PDF and 
again will not be affected by changes to the included PS.

-- 
Odysseus

Aandi is correct, many applications output "Private Dictionaries" which contain the file in the application's native format or contain data which allows them to reconstruct the native format.

Also, you could just be seeing the image preview in some situations, not your edited PostScript code.

Also, the concept of "text fields" just doesn't exist in PostScript. What you perceive to be a single field or string is just a collection of integer values that index to a font dictionary. Your driver or application may split these up into any subset in order to precisely control the placement of glyphs on a page. Therefore any "search and replace" mechanism you attempt to write is bound to either 1) fail miserably or 2) work only within the confines of a very, very strict environment: same app/version, OS, driver etc.

Thomas D. Greer
www.tgreer.com