View Single Post
Old 05-29-2025, 01:28 PM   #5
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,928
Karma: 6361444
Join Date: Nov 2009
Device: many
You are on a Windows box or on a MacOS box with a case-insensitive file system right? Windows and Macs do try to preserve case (remember the way you really typed it) but is still case insensitive underneath. (so styles maps to Styles and visa-versa).

On a OS that has a case sensitive file system, this is not true (MacOS if the user enables it, Linux all the time, etc).

The key is that by definition, hrefs are case sensitive and "styles in not equal to "Styles" which is true for all url path elements across the web.

I have never liked case insenstive file systems but Windows still seems to be stuck in the past for this. So on my MacOS machine, the first thing I do is reformat the disk to be case-sensitive so that errors like these can be easily caught.

If your epub is ever published and read on a device that is Linux based underneath (read that most of them) then it would be broken. It just happens to work on Windows/some Macs but in reality that is because the file system maps from one to other. The web url spec is clear on how it should be handled by software and browsers.

My guess is that epubcheck would have detected this error. That is a plugin well worth using.

Last edited by KevinH; 05-29-2025 at 01:35 PM.
KevinH is offline   Reply With Quote