Skip to main content
1-Visitor
November 2, 2006
Question

using relative graphic paths

  • 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

    17 replies

    1-Visitor
    November 2, 2006
    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?
    1-Visitor
    November 2, 2006
    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
    1-Visitor
    November 2, 2006
    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


    1-Visitor
    November 2, 2006

    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
    1-Visitor
    November 2, 2006
    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
    1-Visitor
    November 2, 2006
    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.
    1-Visitor
    November 2, 2006
    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
    1-Visitor
    November 2, 2006
    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

    1-Visitor
    November 2, 2006

    [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
    1-Visitor
    November 2, 2006
    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.