Skip to main content
1-Visitor
November 20, 2013
Question

lost graphics

  • November 20, 2013
  • 8 replies
  • 1832 views
There are days I just hate working in markup. The past couple of them are to
be included.

First testing some changes (migrating a DTD to schema) and spent hours
getting little things fixed.

Now all my graphics have stopped displaying. Just BOOM there one day, gone
the next.

I've gone through and verified the ENTITES are still there, tested the file
with the DTD rather than the schema and still no graphics.

Other things I've checked are to ensure the 'promptgraphicsbrowser' is set
on (a common problem in the past and the default is set to 'on' so it
doesn't even appear in the Epic config file), verified paths, opened the
graphics in an external viewer. Made sure the graphics toggle is set to view
graphics (but when they don't even show up in print preview that isn't the
issue).

I have tested this on three different machines using Epic 5.4 and/or Epic
6.0. This is the only DOCTYPE that is giving me this problem. So it has to
be something in the way this is called.

I DO NOT use the Epic 'custom' folder.

I am at a total loss right now. Anyone want to tell me what really obvious
thing I'm doing wrong. I promise I will dutifully bang my head on a brick
wall when it is pointed out to me.

Lynn

    8 replies

    November 20, 2013
    Can you do an access($graphicfile) at the command line and see if what the entity points to is resolving? Have you moved anything at all that might have a relative path or a base path? That's usually what hoses me. Also, are you going from SGML to XML?
    18-Opal
    November 20, 2013
    Hi Lynn--

    You could try verifying that the graphics path is resolving things correctly, via something like this:

    logofile = find_file_in_path("logo.gif", "r", option("graphicspath"));

    If it's not found, then something may be wrong with your graphics path preference.

    Also, just to verify, you didn't make any changes to your DCF file, did you? If so, you might need to double-check it and make sure the element definitions for graphic elements are still correct.

    --Clay
    LynnHales1-VisitorAuthor
    1-Visitor
    November 21, 2013
    Clay and Jason,

    Thanks for the ideas. I've tried several different checks and I am getting
    mixed results. I need to play with things a bit more to see what is
    happening and why I'm getting the different returns. One says the path does
    not exist (but the XML is in the same path) and another says everything is
    ok.

    I've looked at the DCF for two DOCTYPEs and the graphic entries are
    identical. One works, the other does not. So to say I am getting confused
    right now is to put it mildly. 😄



    I'll post what all I've done and the results from both the working and
    non-working documents tomorrow.



    Lynn


    LynnHales1-VisitorAuthor
    1-Visitor
    November 21, 2013
    Well here are the results of my further testing.


    Epic function

    Working DOCTYPE

    Non-working DOCTYPE


    Graphics displayed (not a function)

    yes

    No


    entity_path(oid_attr(oid_current_tag(), "boardno")) (HELP 5728) (NOTE: the
    'oid_attr()' provides the 'name' required for this function.

    Full path and file name

    Full path and file name


    Access(graphic-path\file-name) (HELP 608)

    0 (not found)

    0 (not found)


    Find_file_in_path() (HELP 2133)






    With "OPTION"

    null

    null


    Without "OPTION"

    null

    null



    One thing I found interesting is the 'find_file_in_path' function. When I
    did my first tests with it last night, IF I used the "option" before the
    path, I got one path, if I DID NOT use the "option" I got another path. Now,
    regardless, I am getting a null string across the board.



    I have double checked my DCF and even copied the graphic element from the
    working DCF DOCTYPE to the non-working DOCTYPE. Still not seeing graphics.

    That corollary to Murphy's law I saw a few years ago certainly applies now.

    "To err is human. To really foul things up requires a computer."



    Lynn


    18-Opal
    November 21, 2013
    Hi Lynn--

    The next thing that comes to mind would be to check any doctype-specific ACL files that might be making changes to the graphics path or other graphics-related preferences.

    It might be worth checking the graphics path under both doctypes, just to make sure it is the expected value in both instances. You can use

    response(option("graphicspath"))

    Maybe also check option("graphicdisplay") for both doctypes.

    --Clay
    LynnHales1-VisitorAuthor
    1-Visitor
    November 22, 2013
    Clay,
    18-Opal
    November 22, 2013
    Hi Lynn--

    Aha. Nice detective work. Now that you mention it, I can see why it might be tricky to make XSD and entities play nice together. I think the general perspective is, if you are using XSD, then you should be doing things the proper XML way, which would include moving away from entity use for anything other than maybe numeric character entities.

    I guess the thing to do now is look carefully for any differences in the way the notation is defined for the graphic that works vs. the ones that don't. It may be something as simple as case, e.g. jpg != JPG or something like that.

    Good luck!

    --Clay
    LynnHales1-VisitorAuthor
    1-Visitor
    November 25, 2013
    EUREKA.

    It took me a while, but I FINALLY found the answer. But to prolong the
    agony, here are some of the steps I took to find the solution.





    Epic function

    Schema

    DTD


    count_notations

    All 0

    Lists used


    notation_exists()

    Y

    Y


    notation_source()

    1

    -1


    oid_graphic_format()

    null

    OK


    oid_graphic_viewer()

    null

    null


    graphic_tag("graphic")

    0

    1


    dcf_validate()

    1

    1


    doc_type_dcf_file

    null

    OK


    graphic_entity_attr_name()

    null

    OK


    graphic_tag()

    0

    1


    graphic_tag_name()

    null

    OK


    entity_exists()

    1

    1


    entity_path()

    OK

    OK


    oid_declared_tag()

    1

    1


    doc_type()

    OK

    OK


    doc_type_file()

    OK

    OK









    Now all the functions were properly filled in as needed (like
    'notation_exists()' requires a notation name which returned the correct
    response when I entered a graphic type notation name).

    A couple don't look right, for instance the -1 on 'notation_source()' means
    it is not declared, but it is visible in the DTD file.

    The first key to the problem was when the DCF did not respond as valid for
    the schema. The DCF is in the same folder as the DTD. So that was weird. It
    was also (to a degree) the problem.

    The final clue was when I ran the 'doc_type_file()' function. I use this
    routinely to get the path of the DTD/schema/style sheet. But it finally hit
    me that the DTD and schema names are not the same. So the DCF is reading
    DTD/Schema name and NOT based on the folder it is contained in.

    When I converted the DTD to schema, I used two conversion tools to see which
    I liked the best. Both Oxygen and XML Spy can covert a DTD to a schema, so I
    named their schemas with a '-ox' or '-spy' to tell which one I was working
    with. Now the DCF is looking for the base name, no extra El Toro Poopoo.

    When I changed the name to be the same as the DCF, everything started
    working as advertised. Well my GIF file still isn't showing up, but that is
    another problem (that cost me a day of troubleshooting though).

    I knew it would be something obvious, but I just didn't think DCF name to
    schema name. L So if you all will excuse me, I am going to step outside and
    hit my head against the brick wall that is the side of my house. Hope I
    don't damage the house.



    Lynn