Another computer question...

Black Hole

May contain traces of nut
Win7/64

I use a program (KompoZer) which does mostly what I want but is annoying in that it fails to open files in certain very specific circumstances (loading CSS and images etc that are referenced from root instead of relative to the current location). BlueGriffon (another development of NVu) does exactly the same thing.

My idea is that if I could log file requests made by KompoZer, I could see why it isn't finding root-referenced resources and work out a way to plug the gap. How could I go about that? Is it possible to run a virtual environment to intercept the file system calls?

Another idea is to examine the source code - if it's well enough commented I might be able to spot the area of code that does it (but it sounds like a long job).
 
As there is a lack of intelligent replies...
I'm not sure what you are doing that requires files to be located from root and why.
I have a very vague recollection of something similar using Dreamweaver - but that was over 15 years ago - and that was me doing something stupid!
An example of the problem could be helpful. eg. layout of files on the source disk, the intended layout of the website, and the failing references.
 
KompoZer/BlueGriffon (WYSIWYG web page editors, both based on NVu) load page resources fine as long as the path is relative to the current page, but not if they are relative to the root URL. For example (illustrative only):

On the web server:

<my_url>/index.html​
<my_url>/assets/image1.jpg​
<my_url>/pages/page1.html​

On my PC:

M:\index.html​
M:\assets\image1.jpg​
M:\pages\page1.html​

Supposing page1.html contains <img src="/assets/image1.jpg" alt="whatever">, it will display fine in a browser pointed at file://M:/pages/page1.html or http://<my_url>/pages/page1.html, but KompoZer won't load the image when editing page1.html.

If, however, page1.html contains <img src="../assets/image1.jpg" alt="whatever">, it will display fine in browser and KompoZer, but the code is not now relocatable because it requires image1.jpg to be located at a particular place relative to the current file.

My first thoughts were that if I could work out why KompoZer isn't finding the image file (it takes a while before it gives up), I might be able to adapt my disk structure to accommodate it. Therefore I was looking for a debugging aid.

I'm now thinking that if I were to move the KompoZer executable to M:\, that might solve the problem (can't try it right now). What KompoZer needs is a means to set the disk location of "/", either as a setting or as a command line parameter or system variable, then my page hierarchy could be located anywhere, not just as root in a virtual drive letter.
 
I'm now thinking that if I were to move the KompoZer executable to M:\, that might solve the problem (can't try it right now). What KompoZer needs is a means to set the disk location of "/", either as a setting or as a command line parameter or system variable, then my page hierarchy could be located anywhere, not just as root in a virtual drive letter.
How does it know that its root is M:\ at the moment then? You must have to tell it somewhere, surely?
I would suggest using M:\something for the root folder (in case it's trying to access M:\\assets\image1.jpg)
It's weird how it appears not to apply the same rules for .htm files as .jpg files though.

I can't see how moving the executable will help, given that it appears to be somewhere else which has no association with M:\
 
How does it know that its root is M:\ at the moment then?
Because the current file is on M: and M:\ is what you would get if you did "dir \"

I can't see how moving the executable will help
Because there's a chance it is looking at the root of the drive it's executing from. As soon as my PC has stopped thrashing from a rash decision I took to update* Windows lunchtime, when I was going out for a couple of hours, I'll give it a whirl.

* I usually avoid it because of the loss of productivity!
 
Now that I have acquired an old version of KompoZer (for Win XP :eek: ), and given your sample layout, let me have a look and compare with [an old] Dreamweaver and see if I can replicate the problem. Then it might be possible to make some suggestions - unless prpr gets there first. It might take a while as I'm struggling to do one thing at a time, let alone half-a-dozen.
Edit: Probably should have written, I will look at it when I get a round tuit.
 
Last edited:
I can't see how moving the executable will help, given that it appears to be somewhere else which has no association with M:\
If someone hasn't coded KompoZer properly it could make a difference. But it doesn't matter now:
Yeah, well, it was worth a try (but no dice).
I tried to package one of my Java applications with PortableApps portable Java runtime and it complained because something was in the wrong place relative to the program. My guess is that I've cocked up (and not by using Java either ;) ).
 
Another idea is to examine the source code - if it's well enough commented I might be able to spot the area of code that does it
And then what? You need to be able to build it. I don't know how easily it builds, but usually it's a nightmare.
You didn't say which version you were using either.
 
Okay. I'm using an old version of KompoZer (and I find it a bit cack-handed to use).
To get this to work the source html file needs to contain the full path as in file://M:/assets/image1.jpg. I had trouble saving this file - but when I did, it saved with that link there. When published the link changed to .../assets/image1.jpg. When I re-opened the source file (which I found to be a pain, I kept re-opening the web page for editing) the link was the full path and the image showed up as expected .
Not sure if I've made that clear, or whether it answers your problem. And I forgot to check whether the source file worked properly in the browser (I can't check at the moment as the USB port is in use for my internet dongle and I put the source files on an empty USB drive :roflmao: )
 
Thanks for your effort, but I don't need input on what to use - I'm trying to find out why root-relative doesn't work (it should) and whether there's any work-around (without changing the .html) I can use to persuade it to work on the KompoZer WYSIWYG editor.

Like I said, root-relative works fine on the server, but to accommodate KompoZer (or BlueGriffon) I have had to adapt the pages to page-relative (which is annoying because if I reorganise the structure the links have to be altered - not so bad with Notepad++ doing substitutions across multiple files). The website is quite small at the moment, but if it gets bigger things like this will become unwieldy.

You didn't say which version you were using either.
If it matters: kompozer-0.7.10-win32. That's the latest, I believe (except for a beta). However, as BlueGriffon does the same thing, it's a fair bet every version has the bug since NVu.
 
Thanks for your effort, but I don't need input on what to use - I'm trying to find out why root-relative doesn't work (it should)
Fair enough. I only chipped in because no one else was answering.
Therein lies the problem. I've had a look with DreamWeaver and root relative which it states should work, doesn't. I'll clarify that. <img src="/assets/image1.jpg"> works within DW but not for the local version of the site within Mozilla browsers (well, the versions I've got). It works in IE8. It exports to the website as a document relative ("../assets/image1.jpg"). If I correct it so that Mozilla browsers work on the local copy, DW can't display the image. This is very similar to your problem. In fact, I'm fairly certain this is the problem I had years ago...
I have had to adapt the pages to page-relative (which is annoying because if I reorganise the structure the links have to be altered
... and that was my solution, along with manually editing the html! When you're dealing with four sites each of 50+ pages, it's a right PITA.
I don't think you can persuade the various WYSIWYG's to do what you want (unless someone knows better). You may have to accept that root-relative doesn't work as advertised.
A final thought, I just wonder if KompoZer is having trouble with how Windows handles files. Have you tried using KompoZer for linux?
 
Another musing: can anyone enlighten me how the Internet actually works?

When the American academic institutions started to connect their mainframes together, that would (I imagine) have been over leased lines point-to-point, and the protocols gradually developed to be able to do packet routing so that packets got to their final destination no matter how many nodes they had to pass through.

What do we have now? Who are the nodes on the modern primary network, and how are those nodes connected together? Who controls the interconnecting medium?

I pay for access through an ISP. I imagine at least some ISPs rent capacity from somebody else rather than owning their own capacity. Somewhere up the chain there is somebody who owns the actual real infrastructure which processes packets and has direct access to a trunk network, and somebody (maybe the same somebody) whose business it is to transmit any particular packet from point A (one end of a wire or wireless link) to point B (the other end) without any knowledge of the contents of that packet.

Who are these "somebodies", and how is it we can communicate over their infrastructure for practically nothing... particularly considering the enormous cost of a trans-oceanic cable or a satellite relay?

Then you've got the facilities which create the World Wide Web to make something generally useful of the Internet - the means to catalogue IP addresses and assign them to textural addresses, and the means to search. Obviously, search is taken care of by the likes of Google, and we know where they get their revenue from, but how do the DNS servers get paid for?
 
I found some, if not all, the contributers to that podcast annoying rather than amusing. Unfortunately it sent me to sleep, so I'll have to listen again. Argh! It answers some of the questions. But I don't remember it saying who pays for the transatlantic cable etc.
 
It answers some of the questions.
It talks vaguely and anecdotally from which one might surmise the answers to some questions. The indications are that the Internet is comprised of nodes and ad-hoc point-to-point connections between the nodes, and it hints how the nodes come about, but (apart from nodes that exist within one locality) there is no suggestion how the point-to-point connections are implemented. Back to leased lines again.
 
Back
Top