Re: Where have all my pictures gone?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Ulf-D. Ehlert skreiv: > Kolbjørn Stuestøl (Samstag, 30. Mai 2009, 18:50): > >>> Can you open the image file clicking on the link >>> html/no/images/filters/options-logo-3d-outline.png? >>> >> No such contents in the html/no/images. This is still a link to the >> xml/no/images >> > > Yes, but you should be able to ignore this and enter html/no/images as > if it was a real folder (but it's probably not important, so forget > it). > [...] gimp-help-2/html/nn/images/filters/options-logo-3d-outline.png returns "File not found" [...] gimp-help-2/html/nn/images.lnk gives a frame in the browser's window containing the full file name and a clickable link named "Up one nivau" (or what it would be in English). Clicking on it opens a list showing all the files in the html/nn folder including the images.lnk as links. (As in ftp listings). Clicking on the images.lnk opens the first page again. Not the xml/images as I expected. Clicking on the html links opens the file in the browser. > >>> Do you have a "readlink" command (package: core-utils)? >>> If yes, what is the output of following commands: >>> $ readlink html/no/images/filters/options-logo-3d-outline.png >>> >> ../../../../images/nn/filters/options-logo-3d-outline.png >> > > Oops, really ".../images/nn"? (should be ".../images/no") > Yes. (I was working on "nn" and forgot to change. Same for "nn" and "no") > >> If a "no" image exists the pointer points to it, otherwise to the "C" >> image? >> > > Yes. > > >> So the problem lies somewhere in the building of the links/pointers? >> > > No, apparently the links are correct. > > So let's summarize: > o the html files contain correct image references > o these images files are links to existings image files > o you can open an image file even if it's a link > (to xml/no/images/...) > o the readlink utility shows that the links are no dead links > o you cannot open the image (a link) via the browser's URL bar > o all your browsers do not display the images > > Hmm, if this summary is correct (and remember that I haven't any clue > about Windows or Cygwin, so maybe this is a silly question): > is it possible that there's a global option somewhere which prevents all > browsers from dereferencing links? > Your list is correct. The links from the xml catalog works fine from any browser i have tried. The links through html/nn/images.lnk does not work. I think this must be a "global" Windows probblem. > Can you check with a simple test html file whether or not your browsers > can read links to images (and links to links to images) which definitely > exist? > I'm already working on it, and I think your question is not at all silly but relevant. It is a possibility that something prevents the links from carrying properties (options) with them, or that the options must have a certain, very specific, format. Yesterday I made a html page (in Nvu web editor). Also tried Microsofts Front page 2000, but this editor rejected all links. Again: Perhaps a special Windows problem? Adding the image link file:///C:/cygwin/bin/gimp/work/gimp-help-2/xml/nn/images/dialogs/examples/border-selection-01.png.lnk and the image file:///C:/cygwin/bin/gimp/work/gimp-help-2/images/nn/dialogs/examples/border-selection-01.png is displayed in the browser. So the links from the xml/nn/images works fine. On the other side, I have not yet found any way to get the browser recognize the call linked from html/nn/images.lnk. I'll try again this evening. Another solution seems to use one link only by copying the xml/[lang]/images to the html/[lang] and omit the html/[lang]/images.lnk? (Perhaps changing the relative addresses). Yes I know that copying images is time consuming. (All the link files has ".lnk" added although this are not showing up in my file browser). I'll try digging some deeper in the Windows stuff although this is not my occupation. If I stumble over a solution I'll mail it immediately. > > > >>> I get, however, many xslt warnings: >>> No localization exists for "no" or "". Using default "nn". >>> >> It's due to your add in the Makefile.GNU some time ago: >> $(cmd) test "$*" = "no" && lang="nn" || lang="$*"; \ … >> > > Yes, without these changes we would probably get 'Using default "en".' > > >>> I think we should try to replace "no" with "nn" to get rid of them: >>> - replace "no" in configure and Makefiles, >>> >> Yes. >> >> >>> - move/rename "no" directories to "nn" , >>> >> Rename >> >> >>> - anything else? >>> >> Renaming quickreference/po/no.po to nn.po >> Nothing else. >> > > Ok, do you change it? > I have not the permission to commit (git push?) my files, so perhaps you do it for me? Kolbjoern > Bye, > Ulf > > ------------------------------------------------------------------------ > > _______________________________________________ > Gimp-docs mailing list > Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs > _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
[Home] [Video For Linux] [Photo] [Yosemite News] [Yosemite Photos] [Yosemite Book Store] [gtk] [GIMP for Windows] [KDE] [Scanner] [Memory] [GEGL] [Gimp's Home] [Gimp on Windows] [Steve's Art] [Webcams]