using relative graphic paths

Forum|Forum|19 years ago
November 2, 2006
17 replies
1457 views

hi all

is there a way in arbortext editor (5.2 windows) to insert or change
absolute graphic paths to relative ones?

when we access graphics that are in a subfolder of the document, we
get realtive paths. but we have to insert relative paths to access
graphics in a folder structure like

+ project
+ documents
+ images

so the path for a graphic should be ..\images\graphic.gif. arbortext
editor inserts always an absolute path. since graphic_relative_path
needs an absolute path to convert paths and there is always a
different absolute path to graphics.

any help is appreciated.

frank

Show previous replies

C

ClayHelberg

18-Opal

Hi Frank--

There are two parts to this:

1) You would need a function that derives the relative path from the two absolute paths (the document path and the graphic path). I don't have such a function for you, but graphic_relative_path() doesn't seem to do the job. (According to the documentation, at least, it only seems to work if the graphic is in a subdirectory below the directory containing the document).

The basic logic would be something like this (off the top of my head, YMMV):

* find the first k path components of the graphic path that match the first k components of the document's path. Remove the matching components from both paths.
* for each remaining path component in the document path, add a "../" to the front of the graphic path

2) You need to intercept insert graphic operations and use this function to fix up the path that gets inserted into the doc. We use some similar code to make sure only the filename part gets inserted, since we use our own scheme for managing graphic directories that we cooked up before we started using Epic. The code is pasted below. You ought to be able to adapt it pretty easily, the main thing you'd want to change is the "insert()" statement in line 8 of the insertgraphic() function definition. Change "basename($gname)" to "get_relative_path($gname,dirname(current_doc()))", where get_relative_path() is the function you define as part 1 of this exercise.

Good luck!

--Clay

#################################################
#
# Custom Insert Graphic function
#
#################################################

debug("pubrc: defining graphic dialog functions, menus");
function insertgraphic() {
# @@@ add some code to check for valid context
# invoke file chooser dialog
filter = "All graphic files|*.gif;*.jpg;*.jpeg;*.wmf;*.png;*.cgm|GIF Files|*.gif|JPEG files|*.jpg;*.jpeg|Windows Metafiles|*.wmf|Portable Network Graphics|*.png|All files|*.*";
gname = file_selector(dirname(current_doc()),"gif",filter,"Select graphic to insert");
# insert graphic element at cursor
if ($gname == '') { message "Cancelled Insert graphic"; return }
if (!file_is_graphic($gname)) { message "$gname is not a recognized graphic file"; return }
insert("<graphic src="" .=" basename($gname)=" .=" "="><caption></caption></graphic>");
# append path to graphics path, if it's not already there
gpath = get_graphics_path();
if (index(gpath,dirname($gname))==0) {
append_graphics_path(dirname($gname));
}
# undo directory change caused by file_selector dialog
cd $dirname;
}

alias InsertGraphic {insertgraphic();}

menu_change Insert.Graphic -cmd { insertgraphic(); }
map Control+g { insertgraphic(); }

# add new hook to catch insert tag->graphic operation

function insertgraphiccallback(doc,tagname,op) {
if ($tagname == 'graphic') {
insertgraphic();
return -1;
}
else { return 0; }
}

C

ClayHelberg

18-Opal

Hi Ed--

I'm curious about this. For the folks who keep all your graphics in one location, how do you manage them? Are you using some kind of database or CMS to index and serve them up?

Just using the file system, we found that we quickly reached a point where having too many graphic files in the same directory basically made that directory useless in terms of all the usual Windows tools. Trying to open the directory in Windows Explorer would literally take minutes because of the long list of files. Ditto for the Open File dialog in Epic or any other application. Using the "dir" command was almost as bad, because you'd get 87 bajillion screens to scroll through.

For this reason, we use a separate location for each project's graphics, and in at least one instance, the graphics directory for a single project is split into subdirectories, because having them all in a single directory made it too unwieldy.

So, if you're just using the file system, do you have a clever way of avoiding this problem, or do you just suffer through waiting for the long long list of files to appear whenever you need to access it?

--Clay

A

AndyEsslinger

1-Visitor

The relative path to a sibling folder is: ..\image\graphic.gif

It can't be that simple can it?
-Andy
\ / Andy Esslinger F-22 Tech Order Data
_____-/\-_____ (817) 777 3047 LM Aero Box 748
\_\/_/ Fort Worth, TX 76101

E

ebenton

1-Visitor

We don't have any sort of sophisticated graphics management. We simply
have a naming convention for files, and we basically use a number at the
end of the filename to identify the version of the graphic. Our writers
call out the graphics by filename, and they know what version they want
(99.99% of the time, it's the latest version).
Our graphics are on a Unix server. There are slightly more than 28,000
files occupying about 11 G of storage space.
We use EPS graphics with no bitmap preview, which are not displayable in
Epic/Arbortext Editor. This cuts down on performance issues. If the
writers want to see what the graphic looks like in the document, they
can compose PDF and look at it. If an output requires a different,
non-EPS format, we transform the graphic reference to the same filename
with a different file extension and use that file, which is stored in
the same place as all the other EPS graphics.
Our writers have never, ever used a WYSIWYG authoring system, so have
never complained about not having any of the features available in Word
or Framemaker, etc.
Even in the 1980's they were using a markup-type system, with square
brackets to denote typesetting commands. They used to need to queue
their documents to a printer, wait for the result, and make changes
based on that. Today's system is much quicker, but they still don't
have WYSIWYG and still don't miss it, because they never had it.
If we have any new hires that start to complain that Arbortext Editor is
"not like Word", we beat them until they stop complaining.

C

ClayHelberg

18-Opal

Hi Ed--

Ah. So writers just type in a filename (containing a version number) rather than "browsing" for the image, right? In which case, the writers have to know the name of the image they want, but that's probably not too hard if you have the right naming convention.

How are the graphics created? Do the authors create their own graphics, or do you have dedicated illustrators/artists who do them? Do they save directly to the graphics server, or do they save locally and then copy to the server? (I think it must be the latter, otherwise you'd have the problem I mentioned in the "Save" dialog.)

Do you find that this approach limits reuse of graphics? We encourage our authors not to make a new graphic if an old one will do. We have a good deal of shared content, with some graphics being used across multiple projects. In that case, browsing can be very helpful.

Our writers are also very structure-savvy, and they don't pine away for Word or FrameMaker (or at least, if they do, they're smart enough not to do so in my presence ;-). Even so, I wouldn't consider a browse interface for selecting a graphic file to be WYSIWYG-ish. (It is WIMP-ish, but not WYSIWYG.) There is a trade-off between usability and complexity. Too much complexity, and you have Word (with all its inherent problems); too little complexity and you have TROFF. Both are nasty in their own ways. To my way of thinking, browse dialogs are one of the little things that make Arbortext a more productive environment for XML authoring than, say, Emacs or Textpad.

--Clay

B

bibach

1-Visitor

Frank,
One last thought to add to this thread, is that you might
consider adding some code to your DTD (or Schema?) instance.acl file (or
create the file, if you don't have one) that adds an entry to the
"graphicspath" option (the option in Epic that corresponds to the
APTGRPATH environment variable) for the images directory that
corresponds to the document being edited. That way, the author should
be able to just enter the filename with no pathing information at all.
That done, you could probably use a solution like Clay's to
"fix" any pathing information the author may have put in, ideally so
that there is no pathing information at all, since the graphics path
should list all locations having graphics the author wants to use. Or,
if you have control of the DTD/Schema, you might consider setting the
type of the attribute that holds the file name to something like
NMTOKEN, which doesn't allow any slashes, so the user wouldn't be able
to enter pathing information, anyway, though that is a bit more
brute-force.

Brandon Ibach
Lockheed Martin Space Systems
Cape Canaveral, FL
321-476-7051

E

egrubs

1-Visitor

Frank,

This is how I handle it and I have been trying to find
a better way.

I have an ACL file in the "init" directory with
something like this:

append_graphics_path('\\servername\imgid\folder1;\\servername\imgid\folder2;\\servername\imgid\folder3;\\servername\imgid\folder4;\\servername\imgid\folder5')

I certainly hope there is a better way to do this.

--- Frank Marent <frank.marent@emnemics.ch> wrote:

> hi bjarne
>
> > In Preferences, specify a list of directories to
> search for graphic
> > files.
>
> the paths in which we'll have the graphics are
> unpredictable and we
> will have hundreds of these folders with graphics...
> any way to
> handle this?
>
> frank
>
>

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded