cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X

lost graphics

LynnHales
1-Visitor

lost graphics

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 8

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?

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

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


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


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

Clay,

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

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


Announcements

Top Tags