Checking info on a Quark Xpress document

Hi

I’ve written a little 'script to take Document 1 of Quark XPress 6.1 (6.0 was utterly useless), EPS page 1 in a specific location and then save the document in the original files location (as version 6 if opened as version 4.11 as most of them are). The problem arises when I want to double-check that everything worked properly. I do this by comparing the modification date with the current date of the two files. If they are both true then I close Document 1 indicating to the user that everything worked. If not, then Document 1 remains open.

But. When I check ‘info for’ of Document 1 it looks in the /private/temporary location of the local HD instead of the original file location on our server. This causes me problems as this temporary file doesn’t always exist (and more importantly isn’t the file I want to compare against).

I can post the 'script if needed (but it’ll probably shock the better 'scripters among you!). What I want to know is:

Can I find the path to the original open Document 1 on the server instead of the local temporary file? (And how.)

Many thanks in advance. I’ve checked the forums but nothing seems to cover this particular Quark ‘feature’.

I haven’t found a way to get the correct path to a document in QXP6. The only way I’ve found to work around it is to get the name of the document and use the Finder to get the path of the document in the front window whose name is the name of the Quark doc. This obviously requires that the file’s container window is the frontmost Finder window.

This and the facts that many of my Quark print scripts cause it to expectedly unexpectedly quit, the app can’t get the color of an imported image correct the first time about 80% of the time, and it will screw up trapping from an Illustrator EPS file if the clipping paths are layered to its fickle tastes, and I’m ready to switch my whole workflow over to InDesign. But that’s another story.

Thanks Joseph. Unfortunately we don’t use the Finder in the conventional way (locate job folder, select desired file and open etc.) but instead use the Find command every time (they’ve been doing it this way for years and I can’t change their habit).

I have considered using Unix to find the document, then return the path. As yet I’ve not worked out how to do this. I’d have to consider the possibility of there being more than one file with the same name but in different locations. I could get around this by assuming that the user has opened the newest copy (but this may not always be true).

We did consider InDesign but some of the designers aired concern about moving to a new application, but now they wish they’d kept quiet as XPress 6 is causing everyone problems.

Could you try getting the path from Quarks plist, maybe it is stored in there some where?

Sorry? ‘plist’? I’ll go check the archives. :slight_smile:

For the moment I’m just comparing the date modified and size of the EPS file as it is easier.

If sysDate = ModDate and OrgSize does not equal NewSize then tell Document 1 to close

I thought you were trying to get the Path of the File from the server? You could try getting the path from the Quark preference file via a do shell script.

You could also get the document name from Quark and then do a find shell in applescript which would return the path.

Yes, that is what I did. But upon reading the Event Log I noticed that it was getting a local path name for a file opened from the server, yet when saved the file on the server was being updated. I can only assume that Quark have made it so that remote files are copied locally to work on, then save locally then copy back to remote volume. This works, except when you want to get path as I do.

Steve, a plist is a preferences file. The shell script for this is:

defaults read theDomain theKey

theKey would be the key to the value you want. theDomain is the name of the plist file sans the extension. so for QXP, it would be:

defaults read com.quark.QuarkXPress

Unfortunately this file doesn’t hold the path to the front document, for me. gesprague, does your Quark plist hold this info?

The ‘find’ command, though is working well for me. It does take about 11 seconds to find the item, but it will be better on relying on the workaround I posted. Thanks for bringing that up.

I have a workaround provided by Quark. I will probably post it sometime tomorrow after I get it tested (and verfiy permission). Just wanted to bubble this message back up so that it wasn’t forgotton.

This is not true!!! Here is the solution:

  1. open a qxp document from a server

  2. open the terminal

  3. type:

defaults read com.quark.QuarkXPress AppleNavServices:GetFile:0:Path

You will get the path in this form:
file://localhost/Volumes/

GO QUARK SCRIPTERS !!!

uhmmm very strange… now i’m getting always this path for every document I opened
i spoke too quickly :?

this is just the path of the last opened document… Top of the recent document :frowning:

So this workaround could work just if you have one opened document at a time…

uff

Here is a well-formatted applescript code to do what we would like to do :wink:

set qxdPath to do shell script "defaults read com.quark.QuarkXPress AppleNavServices:GetFile:0:Path"
-- Where is the document?
set theTrimmedPath to trim_line(qxdPath, "file://localhost/")
-- The document is on a server
if theTrimmedPath begins with "Volumes/" then
	set theTrimmedPath to trim_line(theTrimmedPath, "Volumes/")
end if

-- Then we need a real old-fashioned Path ;-)
set theRealPath to replace_chars(theTrimmedPath, "/", ":")

on trim_line(this_text, trim_chars)
	set x to the length of the trim_chars
	repeat while this_text begins with the trim_chars
		try
			set this_text to characters (x + 1) thru -1 of this_text as string
		on error
			-- the text contains nothing but the trim characters
			return ""
		end try
	end repeat
	return this_text
end trim_line

on replace_chars(this_text, search_string, replacement_string)
	set AppleScript's text item delimiters to the search_string
	set the item_list to every text item of this_text
	set AppleScript's text item delimiters to the replacement_string
	set this_text to the item_list as string
	set AppleScript's text item delimiters to ""
	return this_text
end replace_chars

the trimming and replacing sub-routines come directly from the official AppleScript website. If you need the complete-original QuarkXPress Path you could add the name of the document at the end of theRealPath variable…

Cheers,
Luca

lucabassini:

You don’t have to go thru all that trouble. With a file:// reference, just trim it off then ask System Events for the path of the item. If it begins with “Volumes/” you don’t have to trim anything, just get System Events to give you back the item’s path.

Could you please post an example?

Any news on the offical workaround given by Quark?

Sorry it took so long, I wanted to test it out, and this is the first chance I had to reply.
It is a hack, and it requires much more effort than what should be required, but it works, and I haven’t had any difficulties with it yet. It works on 10.3.3, I think it will work on Jaguar 2.3 with a patch.

1.) Enable access for assistive devices in Universal Access

2.) Quark Pref Pane. Select “File List”, enable show full path
2a.) Also recommended to increase max num file to 9, in case there are a large number of documents open.


tell application "QuarkXPress"
	activate
	tell project 1
		set oldDelims to AppleScript's text item delimiters
		set AppleScript's text item delimiters to ":"
		set fileName to name
		set FilePath to my getFilePath(fileName)
		display dialog "Path is : " & FilePath
		set AppleScript's text item delimiters to oldDelims
	end tell
end tell


on getFilePath(fileName)
	tell application "System Events"
		tell process "quarkxpress"
			set frontmost to true
			tell menu " " of menu item "Open" of menu "File" of menu bar item "File" of menu bar 1
				set countInDejavu to count of menu item
				set ret_filePath to ""
				if (countInDejavu is greater than 2) then
					repeat with counter from 3 to countInDejavu
						tell menu item counter
							set ret_filePath to name
							set lastTextitem to last text item of ret_filePath
							tell application "QuarkXPress"
								set lastTextitem to coerce lastTextitem to string
							end tell
						end tell
						if (lastTextitem is equal to fileName) then
							exit repeat
						else
							set ret_filePath to ""
						end if
					end repeat
					return ret_filePath
				end if
			end tell
		end tell
	end tell
end getFilePath

Hope this helps!

lucabassini:

Well, there’s still a little hassle when dealing with file:// paths, but just a bit. You do need a ‘decodeText’ subroutine (like the ones on Apple’s Essential Subroutines > Encoding/Decoding Routines page) to ensure any special characters are properly converted.

set thePath to "file://localhost/Volumes/VolumeName/VolSubDirectory/Some%20Document.ext"
set urlFlag to "://localhost"
if thePath contains urlFlag then
	set thePath to decodeText(thePath)
	set rmOffset to (offset of urlFlag in thePath) + (length of urlFlag)
	set thePath to characters rmOffset thru -1 of thePath as text
end if
tell application "System Events" to return path of disk item thePath

If it’s just a POSIX path, it’s much easier:

set thePath to "~/Documents" -- or "/Volumes/VolumeName/SomeDirectory"
tell app "System Events" to return path of disk item thePath

As far as reading the Quark prefs, I wasn’t able to get anything of value from it. I was reading the prefs from Terminal and it was showing one file opened weeks ago and none of the files I had opened more recently.

The whole circumstance is a debacle as far as I’m concerned. When you look at what grimfish’s Universal Access/GUI scripting solution, it’s downright ridiculous (not your script grimfish, but what it needs to do to get the job done). I mean, we’re talking about getting the path to an open document.

I’m inclined to go the direction of using ‘find’ or ‘locate’ shell scripts, with a combination of mod date checks if the result is more than one item, and maybe looking for a hint in the Finder if the window containing the Quark document is still open. If I can get the prefs file to properly reflect the open document, I’ll consider it, but if it’s unreliable, I’ll probably just use it as another straw to grasp at if there’s more than one document with the same name returned from ‘find’ or ‘locate’.