PKG-012 is invalid?

[slonopotamus]

EPUB specification allows unicode filenames, however epubcheck produces a warning when validates EPUB with non-ASCII symbols in filenames:

WARNING(PKG-012): unicode.epub/OEBPS/test-é.xhtml(-1,-1): File name contains the following non-ascii characters: é. Consider changing the filename.

Is there a reason why PKG-012 warns in this case or PKG-012 should be removed?

[slonopotamus]

There's even a TODO in epubcheck that says that PKG-012 should not be a warning.

[slonopotamus]

I went ahead and submitted #1099.

[rdeltour]

This sound like a reasonable request, although I'm not sure if the WARNING is due to widely-adopted practices, and if publishers rely on that.
Any idea @mattgarrish?

[slonopotamus]

Well, I'm not suggesting to remove it completely but just to downgrade severity as you can see in #1099.

[rdeltour]

Well, I'm not suggesting to remove it completely but just to downgrade severity

Sure, I understand. But the severity USAGE is much less visible in EPUBCheck, and a lot of ingestion pipelines base their acceptance/rejection criteria at the WARNING level. So we need to be extra careful when demoting a long-time WARNING to a lower severity 😊.

[dauwhe]

I tried to unzip one of the EPUB samples with non-ASCII filenames (kusamakura-japanese-vertical-writing.epub) on my Mac, and it errored out:

error:  cannot create /Users/cramerd/Downloads/kusamakura/OPS/xhtml/???.smil
        Illegal byte sequence

This seems to be a known bug on some versions of OSX, but it does illustrate the risk. I wonder if we could at least try to see if something like iTunes Transporter is OK with this?

[mattgarrish]

We note this problem in the OCF spec (going back to 2.0), but it's left to reading systems to figure out how to patch characters if they can't handle them:

Some commercial ZIP tools do not support the full Unicode range and might support only the [US-ASCII] range for File Names. Authors who want to use ZIP tools that have these restrictions might find it is best to restrict their File Names to the [US-ASCII] range. If the names of files cannot be preserved during the unzipping process, it will be necessary to compensate for any name translation which took place when the files are referenced by URI from within the content.

https://www.w3.org/publishing/epub3/epub-ocf.html#h-note-0

It was never supposed to be a warning, to my knowledge, as that breaks our internationalization efforts.

@murata2makoto do you have any thoughts on this?

[rdeltour]

It was never supposed to be a warning, to my knowledge, as that breaks our internationalization efforts.

Yeah, I was actually surprised when reviewing this that this issue hasn't been raised before.

I'm leaning towards demoting it to USAGE (to stick closer to the spec). But I'm hesitating to do that "silently" in the forthcoming maintenance release, or if this should go through CG approval first.

[dauwhe]

or if this should go through CG approval first.

I don't think we need CG approval. The spec is pretty clear, and warns people about potential issues. USAGE seems correct.