Images in subpages named index.md have the incorrect path on Windows/cygwin #842
Comments
|
Interesting. Can you try with this option and let me know if that solves the svg issue? |
|
@d0ugal I tried and it does not solve the issue. |
|
Interesting, I tried with a random SVG I found online and the response headers stated |
|
Ah, I tried again with another SVG file and it worked fine with and without livereload. The content type was correct and the image rendered. Can you let me know your mkdocs version? Either with |
|
As livereload is a simple wrapper around tordano's static file server, I checked and tordano seems to only ever have had one relevant issue filed regarding SVG (tornadoweb/tornado#1637). And according to that issue, SVG files have always been served as @styfle all I can suggest is to make sure you are using the latest release of livereload, tornado, and MkDocs. |
|
Yeah, my best guess is that it is a really old MkDocs from when we hacked together out own server. |
|
I'm running on Windows 10 with Cygwin. |
|
Interesting. Then my new best guess is that this is Windows related. All the versions you are using otherwise are known to be good o think. |
|
I just tried this on Windows 7 and was not able to reproduce the problem. I got the following response (which works fine): And I have the following installed: |
|
Hmm, odd. @styfle Have you tried this with a different SVG file just to ceck it isn't broken? |
|
@d0ugal @waylan Is my markdown wrong? What's the proper way to include an image relative to the current md file? |
|
What happens when you try to load the URL for the SVG file directly? Try going directly to It should simply display your SVG file in the browser. If it does anything else, then the problem is with the SVG file. If it works fine, then the problem is something else. |
|
Oh and so I don't forget, I looked a little closer at what Tornado is doing to determine mime types. It is using the Python standard library function |
|
@waylan I visited I believe the problem is with your markdown parser assuming the images are at the root. <h2 data-sourcepos="1:1-1:10">Diagram</h2>
<p data-sourcepos="2:1-3:19">This is the svg
<img src="diagram.svg" alt="svg" /></p>The mkdocs html is wrong in my opinion, and produces image relative to the root directory: <h2 id="diagram">Diagram</h2>
<p>This is the svg
<img alt="svg" src="./diagram.svg" /></p> |
|
Ok, this is definitely a URL/path related issue. MkDocs does its own thing with internal links (overriding Markdown's default behavior) and it appears that you have found a broken edge case. Neither @d0ugal (AFAICT) or myself considered that as a possibility due to you reporting an incorrect content type. |
|
Damn, yet another time that I wish we didn't rename Markdown files to filename/index.html. |
May I suggest lepture/python-livereload#131. No indication as to whether it will be accepted (if not we could always do our own subclass). And it would be a backward incompatible change (it would break existing third-party links to MkDocs sites), but it certainly solves these sorts of problems. @d0ugal, if you are interested, I can write up a full proposal as a separate issue. |
|
@styfle If it is not important to you, a workaround may be to disable |
|
@waylan Yes I should have told you my folder structure. Here it is: |
Ah, that explains the bug better. Thank you. Because this page is an index page to begin with, MkDocs should not be rewriting the SVG URL. It appears that it is anyway. |
|
We have had problems with |
d0ugal
changed the title
|
I added a test project in #852 that tests every combination of sub pages and referencing images that I could think of. They all work fine for me, so I think this is a Windows specific occurrence of the old index.md bug we have seen before. To test it I just change into the subpages directory and run |
d0ugal
changed the title
Yes is probably is windows specific. I realized that installing python with cygwin makes the system think its *nix and works for most things, however installing python directly in windows behaves a little differently, especially how paths are referenced. My workaround at this point is to create a |
|
I'm glad you have been able to figure out a workaround for now. I'm not sure how to progress with this bug, I'll have a think. |
|
I suspect the problem is that when (windows installed) Python is run from cygwin, it does not report itself as being on Windows. Or at least some variation of that problem. |
waylan
changed the title
|
@styfle its not clear to me, but are you using Windows Python from cygwin or cygwin Python? |
|
@waylan I was using cygwin python package on my local machine and Windows Python on the server which explains why I was getting different results in each environment. |
|
Any news on that bug? In windows 10 the paths are wron in mac the paths are correct :( |
|
Unfortunately, none of the maintainers have access to a Windows machine with a cygwin environment. Therefore, it is difficult for us to debug this. My guess is that some code is checking which system MkDocs is running on and then doing something different with the paths. I assume that the problem is that in cygwin, it is (incorrectly) seeing Windows as a *nix system (Mac, Linux, Unix, etc). But without the ability to confirm the problem, we are unsure of how to fix it. Any debugging help, patches, and/or pull requests are welcome and would move this along. As @styfle noted above, as a workaround, you can use Windows Python rather than cygwin Python to avoid the problem. |
|
I don't know the diference between versions. Just donwloaded v3.6/2.7 from python website. Could you tell me how to download "windows python" version? Thanks. |
|
If you don't know what cygwin is, then you almost certainly do not have is installed (its a Linux environment that runs inside Windows). That being the case, you have a different problem than what is being reported/discussed here. Please open a new issue with enough info to replicate your problem. |
|
I know that cygwin is a compiler... so when you said Windows Python/cygwin Python I thought that should be different "python compiled versions" (I dont know how python is generated/compiled/executed). At the end, cygwind Phyton is to run "mkdocs" in "ubuntu in windows" (or something similar). I will try it and see if it works |
|
I stumbled upon this ticket while trying to get MkDocs to serve SVG files in a Docker container. I just wanted to add to the record that it seems like the Python mimetypes module is looking in certain predefined places for a "mime.types" file - e.g. /etc/mime.types or /etc/httpd/mime.types. It is strange that it does not supply its own file, but obviously that's how it is implemented... Since my Docker image is a minimalistic image based on Alpine Linux, there were no mime.types files. After installing the "mailcap" package containing the /etc/mime.types file, the SVG files are now served by MkDocs in the correct way. I guess this could be the case when running in cygwin on Windows as well. If /etc/mime.types is missing, you will end up with octet-streams for SVGs. |
I am using the following markdown in
index.mdand runningmkdocs serve## Diagram This is the svg The output is correct
However I get a broken image as seen below
It appears that the svg file is served as
application/octet-streaminstead of the expectedimage/svg+xmlThe text was updated successfully, but these errors were encountered: