• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: applescript and graphics programs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: applescript and graphics programs


  • Subject: Re: applescript and graphics programs
  • From: Erik Price <email@hidden>
  • Date: Tue, 11 Jun 2002 16:37:36 -0400

On Tuesday, June 11, 2002, at 03:49 PM, garbanzito wrote:

at 2002 06 11, 09:25 -0400, they whom i call Erik Price wrote:
1. read all files in a folder into an array of new "GraphicFile" objects
2. for each object, determine the app to use from the creator code
(or my own hash key system, though unsure yet if AS has this ability)
and set as an attribute of the object somehow
[...]How does this sound? Feasible? I don't know how to create objects in AppleScript but I am armed with "AppleScript in a Nutshell", curiosity, and a helpful mailing list. If I am going about this the wrong (or even the right) way, please feel free to comment on my approach!

unless you need your GraphicFile objects to respond to
messages, i would not bother with objects, but instead
create a list of records. there are no arrays in
AppleScript. determining AppToUse is a simple test. from
your description, you'd simply default to GraphicConverter
unless a file has an XPress creator code. a hash table would
be overkill, and is not a native data structure. (a few
people have fooled around with creating hash tables; search
the archives if you really want to use one.)

Well, I don't really need a hash table -- if AS supported it then I would use it, but it's not like I need that kind of functionality. And if I were a more experienced scripter I might try it for pedagogical reasons, but at this time I just need to find a solution.

However, it seemed to me that going with objects would be a great way to store information about these files, since there are several different attributes of each file that I need to store and eventually write to the file. If AS supports multidimensional lists (is there such a thing? I'm thinking of an AS analogue to multidimensional arrays), there's no reason I couldn't use those too: one list of lists, each secondary list containing the file information (name, size, etc).

Also, in a limited sense I will be using messages with these objects -- apart from simply storing the file information, I will also be writing this information to a file. It would be easy to write a method to do this. But again, the fact that I know nothing of how OO programming in AS works is probably leading me to think I can do things I can't do. I'm a little more accustomed to OO languages like Java and Python, so when I read that AS was object oriented, this seemed like a way to go.

i think i'd take a closer look at whether GraphicConverter
can handle all the non-XPress types, though. as i
understand, it can only handle EPS by rasterizing it with
Ghostscript. this could be slow and error prone. also, it's
common for an EPS file to have a bounding box larger than
the intended printing size (usually due to sloppy
construction). if this occurs and your database must be
accurate, you may need to hand inspect each EPS.

I think that we may just decide to chalk up EPS files as "vector" and have NULL values for dimensions and resolution. This makes storing information about the file a little less worthwhile, but it is really hard to pin down an actual size on a vector. I am also looking into Image Info, a product from David Lloyd.

note also that some types of graphic files may have multiple
pages (PDF, XPress, Freehand native, multipage TIFF). so the
number of pages might be another piece of information worth
extracting.

Very good point. Hm... yep, another attribute/dbase column would do.

on the whole, i wonder why you wouldn't juat use a media
database like iView or Cumulus.

I know. Sometimes I wish that I had. But at this late stage in the game, this is no longer an option (if it ever was) -- originally I thought that since I was only storing simple information (like sizes, dimensions, resolutions, etc) about files, that MySQL would do the job, esp since it is completely accessible to my PHP application. In a way it does do the job. But I made the assumption that I would eventually find a good way to automate the process of extracting the files' information. Now I am finding that it is a little trickier than I expected. If I could do it all over again I might have just said "invest in Cumulus", but... hey you learn from mistakes right?




Erik




----

Erik Price
Web Developer Temp
Media Lab, H.H. Brown
email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: applescript and graphics programs
      • From: email@hidden (Michael Sullivan)
    • Re: applescript and graphics programs
      • From: Cliff <email@hidden>
References: 
 >Re: applescript and graphics programs (From: garbanzito <email@hidden>)

  • Prev by Date: Re: applescript and graphics programs
  • Next by Date: If folder does not exist ...
  • Previous by thread: Re: applescript and graphics programs
  • Next by thread: Re: applescript and graphics programs
  • Index(es):
    • Date
    • Thread