Hi Derry,

The Hanging-Bug Species in my particular problems, all HTML files (3), are the various .jpg files I use for backgrounds. Any 800x600 .jpg file will do. What I am going to describe here is a variation on the theme, but recall that I said that the publishing hung the other night on each occasion on the .jpg file.

This is now a new story and a different file:

http://members.shaw.ca/rrsknox/khspdial.html

I was not happy with the background .jpg file and tried to delete it. Part of it disappeared --- the part where there were NO objects behind titles (3 at the time). The remainder (it separated into two parts as it were) remained attached to various objects. These were all objects created with with the polygon and vertex editors. It did not attach to the table. I had to destroy the three objects to get rid of it.

I then saved the remaining text and tables (the link backgrounds are table cells) to a new file, created a makeshift web page without any .jpg files, saved it back to the original file name (had to, it's the "home page"), and published without problems.

Going back, I added a .jpg file, published without difficulty:....then realized that I had forgotten to compress the .jpg file and deleted it to replace it with a compressed version. Just for the heck of it I tried to publish after I had delted the .jpg file. It locked. I ctrl,alt,del'td and tried again and it locked again.

That's the story line.

To correct myself, this doesn't make the .jpg file the culprit, it's the consequence of deleting and replacing one. It seems as if in some manner the .jpg file has a love affair with objects for this is not the first time I have seen the "separation" phenomenon. (Could the object vertices somehow be attaching themselves to the .jpg file?)

Again this is correspondence and not causality but the focus on the problem has narrowed considerably.

Now to the salvage job. Hope this helps, No sleep = confusing writing.

Muzz

Robert C. Smith

Hi Muzzy,

Thanks for all the detail. When you first deleted the jpg image ("...not happy with the background .jpg file and tried to delete it."), how did you go about doing that? Did you change the background settings or delete the image file or some other way?

Thanks,
Harpo

Derry or Harpo

New picture and the Board be hanged because it stays until you see it,

I saved "to file" instead of "save" and got this thing to publish; i.e. after I deleted the .jpg to replace it with a compressed version.

http://members.shaw.ca/rrsknox/khspdial.html

Look closely under the Title. Beneath "Warm" and "
To You" are two cyan-bluish bulges. They are part of the .jpg file that separated upon deletion. You can also see it sticking out each end.

You provide the answer why that would make it hang on four successive publishing attempts until I saved to file and THAT is the last you will have to read about it from me. Guarantee it.

Muzz

Robert C. Smith

It got cleaned. It was sitting on my SVG display clear as day. Somewhere it got cleaned and that allowed it to publish. QED

Summary: My HTML publishing problems are being caused by the attachment of .jpg remnants to objects whenever I delete the .jpg file.

Sixteen pages in one sentence. Ain't life a hoot.

Muzz

Robert C. Smith

But when you first deleted the jpg image how did you do that?

Sorry Harpo,

Haven't slept in a bit and missed your post.

I select the object with the "drop-down" box, then use Edit/Delete. I.e. I highlight the .jpg file in the same manner I would for any operation such as text-editing, then use Edit,Delete.

(I hope this is the wrong way.)

Muzz

Robert C. Smith

I claim the .jpg file from wherever with the "image editor." It then gets assigned an objx name which I usually rename bkgd1. Then, in the drop-down box where object names hang-out, I highlight "bkgd1" which "lights" up with the rectangle (usually) around it. I then go to Edit and delete it. It asks if I really am set on doing this, then I click OK.

This problem has happened with .jpg's in SVG files also; but they are always the 800x600 size ones which cause problems; situated "to the back."

Sorry I lost the smoking gun.

Muzz

Robert C. Smith

Ok, yes that is is the right way to delete an image object. I was thinking of the page's background image which requires selecting another type of background and doesn't have a delete option.

The image renamants you saw were likely just images left in your browser's cache.

You have not explained why the .jpg image image separates into multiple parts which remain "in cache" while the rest, not involved with objects, exits "cache." Harpo, I had to delete the object to get rid of the "cache" component the first time round. Now I know that cache can be very stubborn, darn stubborn in fact, but you then have to explain how cache blocks publishing.

Whatever the precise mechanism, I saw the "smoking gun."

Muzz

Robert C. Smith

Hi Harpo
You have to keep in mind in mind that I have now, in retrospect, had this happen four times on three different data sets.

Whose cache are we talking about? Mine or the server's or both. Sounds like a dumb question but I have to ask.

Muzz

Robert C. Smith

We are still looking into to ways that deleting an image as you described might cause a lockup. We haven't found anything yet but that sounds like that may have been a factor.

I only mentioned the cache as an aside to let you know that the remnants you saw can be considered 'normal' and were most likely unrelated to the lock-up problem. You can expect to see such remnants when testing multiple html builds on a web server where the images change content but have the same name.

This is what is happening:

When, if building to HTML, a picture is placed behind another object that has transparent portions, the picture will be rendered as part of the background of the object unless you have turned the Geometry Editor's 'Render Background' option off.

For instance, if you have a hollow rectangle that partly overlaps a picture, so the that picture can be seen inside the rectangle, then the geo4p86.jpg file (or whatever the rectangle image ends up being named during publishing), will be a bitmap of a rectangle with the picture inside part of it. If you remove the picture object and re-publish, The geo4p86.jpg will just be a picture of a rectangle.

If you have already viewed the first example in your browser, then when you look at the second example soon after, the browser may not load the second version of geo4p86.jpg from the server because it does not know the file has been changed. It will use the version in it's cache instead. The main part the picture does not show up because it is no longer referenced at all but the cached geo4p86.jpg still contains a piece of it. None of this will affect what somebody viewing your site will see unless they are viewing all the test versions too. You will need to adjust your browser's caching options if you to want to affect this.

Hi Harpo
Thanks a bunch for the detailed explanation. I was reaching the point where I was reluctant as hades to delete a .jpg object anymore. I'll have a look at the geometry editor.

Another strange correlation issue is the loss of the file name when saving via "save as". Once you have established an .ims file, each time you use the "save as" option (I became suspicous of "save" based on the lack of disk activity on my computer) the .ims name should appear and you should merely have to press "save" and "confirm ovewrite."

But on these "problem datasets," there have been several occasions on each dataset when the .ims file name has been missing when I use "save as".
Probably spurious information except in this sense: it doesn't happen on my healthy .svg datasets ever, and thus indicates, perhaps, a general breakdown in the .html .ims file's "book-keeping" system. That is why I have defrag'd the computer several times to see if it would help. In other words, and I realize the inadequacy of metaphor, but when I am working with these files, I get the impression that they are "confused" about their identity.

It is again inadequate information, but somehow relevant, that as I have learned to protect myself by cutting down on the number of saves and publishes as I work, the publishing problem has not re-occurred. Again metaphorical, but the longer I work on the dataset, the more deletions, the more saves, the more publishes,,,,,the greater the odds of a publishing lock.

But somehow the .jpg file was the significant component because that is where the publishing locked on each and every occasion. It is first out of the box, and that is where it locks.

Now there are many other factors involved in commencing a FTP connection, so again the above could merely be coincidence. BUT, the lock occurred immediately after the deletion and replacement of the .jpg object in the most recent example. Details about the others are starting to faid in mind, but .jpg deletions were involved.

AndyP said that he had experienced the problem at random, but I know no details. It would help if he could remember any specifics. Andy??

Thanks,
Robert

Robert C. Smith

Firstly, the reason I publish so often in SVG is that the .jpg object does not dispaly in preview although it will for HTML. Am I missing something?

I created this SVG page yesterday:

http://members.shaw.ca/rrsknox/kfcontcx.html

I deleted and changed the background .jpg file about six times in the presence of other objects. I published dozens of times while making change after change. AND NOT ONE PUBLISHING BURP. --- and no .jpg image separation.

What was different?: only three things a) I started from a completely new page and did not modify an existing data set b) it was SVG and not HTML c) I turned off the "rendering background" option in the geometry editor

The next page to be created will be built out of the above one. It is thus "testing" time

(Having publishing problems here though.)

RC.

Robert C. Smith

Hi Muzzy,

OK, let us know how to replicate anything and we'll track it down.


- Derry