using relative graphic paths

[frank.marent]

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

[bjarne.melin]

Hi,

In Preferences, specify a list of directories to search for graphic
files.

Make sure you have all paths to your graphics listed in
Tools/Preferences/File Locations, Graphics.
The path separator on windows is ';' - and remember, no space!

///Bjarne

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

[frank.marent]

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

[bjarne.melin]

Hi Frank,

I dont know any elegant solution for that case.
However, the online 'help472' says: There is no limit for directories,
but maximium allowed charcters in file locations: Graphics is 4095,
so I think most of the locations will fit.

Editor will search all the listed paths for graphic files and only
insert the file name.

///Bjarne

[AndyEsslinger]

Be careful, the path separator is ';' for Windows but is ':' for Unix.

I use something like this for Windows:
set APTGRPATH=.\gfx;\\server\sharename\graphics

And this for Unix:
set APTGRPATH=./gfx:/home/graphics/category

If the graphics are on the same filesystem you can probably change
absolute paths to relative, but on different filesystems you would
probably be stuck with absolute paths.

As a general rule I do not allow spaces or underscores in graphic names
because it causes problems of one kind or another.

Hope this helps,
-Andy
\ / Andy Esslinger F-22 Tech Order Data
_____-/\-_____ (817) 777 3047 LM Aero Box 748
\_\/_/ Fort Worth, TX 76101

[frank.marent]

andy, bjarne

your information is very helpful but i can't predict all possible
pathes used for graphics. how can i change *any* path in arbortext
editor to a relative path to the document?

frank

[ebenton]

I do not know any details about your infrastructure or who creates your
documents and how you get them or where they and the graphics are
stored, but I strongly suggest that you (as an organization at least)
get some control over this.

[AndyEsslinger]

Frank,

You cannot set an "infinite" number of graphics paths in your
preferences so that every possible directory is the default graphics
path. The very idea is counterproductive.

What do you mean by: "... relative path to the document"? I would think
you mean either .."relative path to the graphic" or "relative path from
the document".

As to how you change it, it depends on how you set up your graphics.
All of my stuff is SGML, but some DTDs are set up for graphic entities
and some are set up for graphic filenames. There may also be some XML
way that I wouldn't know anything about.
Examples:

DCF setup for graphic Entities:
<graphic element="graphic" entity="boardno" <!--(other=" items=" removed=" for<br="/>clarity)-->/>

The boardno would contain the entity name and the entity declaration
would contain either a relative path or absolute path to the graphic or
a Formal Public Identifier.

As a SYSTEM reference:


Or as a FPI reference from a catalog:
cgm>

<graphic boardno="quatz"></graphic>

DCF setup for graphic Filenames:
<graphic element="grphprim" filename="external-ptr" <!--(other=" items<br="/>removed for clarity)-->/>

The external-ptr would contain either a relative path or absolute path
to the graphic.

<grphprim external-ptr=".\gfx\graphicfile.cgm"></grphprim>

Hope this helps,
-Andy

\ / Andy Esslinger F-22 Tech Order Data
_____-/\-_____ (817) 777 3047 LM Aero Box 748
\_\/_/ Fort Worth, TX 76101

[gary.t.nadeau]

Frank,

When you are speaking relative path, are you saying your graphics are in
the same directory as your smgl/xml document or a sub directory?
My thought would be to first break the fingers of whoever is making
absolute paths, then create a perl script to go through the document and
change the graphic entities. We've did a similar thing when we forced a
solid directory structure on our authors. Now if there is a problem, we
just quickly launch that script and is fixes the document.


Gary Nadeau
Tech Lead - Data Support
Maintenance Information Systems
Boeing Integrated Defense Systems - St. Louis
' Phone: (314)233-5231
* Email: gary.t.nadeau@boeing.com

[frank.marent]

[ed]

> I do not know any details about your infrastructure or who creates
> your
> documents and how you get them or where they and the graphics are
> stored, but I strongly suggest that you (as an organization at least)
> get some control over this.

educational enterprise with around 500'000 pages of content to
handle. we have thousends of projects, books, lessons that are
handled between authors and editors and our printing house. we have
control over all our content and can still not predict all possible
pathes to all projects/graphics in 25 different decentralized locations.


[gary]

> My thought would be to first break the fingers of whoever is making
> absolute paths, then create a perl script to go through the
> document and
> change the graphic entities. We've did a similar thing when we
> forced a
> solid directory structure on our authors. Now if there is a
> problem, we
> just quickly launch that script and is fixes the document.

that helps to see that there might *not* be an arbortext editor
onboard solutions to force relative paths to graphics...? perl is a
possible solution for that problem, but we would like to find an
arbortext editor onboard solution.


[andy]

> What do you mean by: "... relative path to the document"? I would
> think
> you mean either .."relative path to the graphic" or "relative path
> from
> the document".

sorry for that. i mean a folder structure like

+ project
+ documents
+ images

where there is always a ..\images\graphic.gif path to the graphic
images. and the problem is, that when we are working (in an xml
environment) with a graphics *subfolder* everything is fine and we're
getting a 'image\graphic.gif' path. as soon as we're working with a
'sister folder' for the graphics as shown above, we're getting
absolute paths from arbortext editor.

it is no problem to solve this absolute path problem let's say in
xslt for later processing. but we should work in arbortext editor
already with relative paths. is there a way?

thanks for all people taking time so far to help me on this.

regards
frank

[ebenton]

I realize that this might be expensive, but you might want to invest in
a server to store the graphics and get your contributors to send you the
graphic files as well as the document files. Then you could store them
all in one place and use it for your APTGRPATH value. Managing them
might be problematic, but probably only if you needed to keep a history.

[ClayHelberg]

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)=" .=" &quot;="><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; }
}

[ClayHelberg]

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

[AndyEsslinger]

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

[ebenton]

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.

[ClayHelberg]

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

[bibach]

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

[egrubs]

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
>
>