This is the first patch to bring jpeg-xr support to webkitgtk+. Rough implementation is available in my github repo. [1] Unlike libwebp, libjxr package does not exist in linux based platforms. Debian is the only platform having the package. So libjxr needs to be added to jhbuild module. [1] https://github.com/shivamidow/webkit/commit/4ef74200d24623a3faca8bf2b55199a6295db1ab
Created attachment 249826 [details] Patch
Comment on attachment 249826 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249826&action=review > Source/cmake/OptionsGTK.cmake:39 > +find_package(JPEGXR REQUIRED) I don't think this should be required. > Tools/ChangeLog:13 > + * gtk/jhbuild.modules: We download a libjxr tarball from debian ftp server since it's hard to indicate > + the correct address where the tarball exists at. We will use jxrlib-1.1 which is almost latest. This is unfortunate . . . > Tools/ChangeLog:16 > + * gtk/patches/jxrlib-bug748590.patch: Added. Minor build fix. The debian version doesn't build? or is this a debian patch? > Tools/ChangeLog:18 > + * gtk/patches/jxrlib-usecmake.patch: Added. jxrlib doesn't provide autogen.sh nor configure. > + Only Makefie is provided, but it does not fit jhbuild system for webkitgtk. Fortunately any debian Really? Isn't there any other serious alternative to jxrlib? > Tools/gtk/jhbuildrc:23 > -jhbuildrc_common.init(globals(), "gtk") > +jhbuildrc_common.init(globals(), "gtk") What is this change about? > Tools/gtk/patches/jxrlib-bug748590.patch:3 > +Author: Mathieu Malaterre <malat@debian.org> > +Origin: upstream, https://jxrlib.codeplex.com/SourceControl/changeset/04cf339385b8196f98025b43a366a0790deac994 I see it's a debian patch now.
JPEG-XR is patented by Microsoft [1]. Do you have any examples of web content that uses this format? Additional image formats impose a burden on the maintenance of a port because they are common vectors for security vulnerabilities. I do not think we should add support for formats that have little or no web content. 1. http://en.wikipedia.org/wiki/JPEG_XR#Licensing
At the very least, this should be discussed on the mailing list before integration into the source tree.
Comment on attachment 249826 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249826&action=review >> Source/cmake/OptionsGTK.cmake:39 >> +find_package(JPEGXR REQUIRED) > > I don't think this should be required. O.K REQUIRED is removed. >> Tools/ChangeLog:13 >> + the correct address where the tarball exists at. We will use jxrlib-1.1 which is almost latest. > > This is unfortunate . . . Indeed. MS provides us a download site here http://jxrlib.codeplex.com/releases/view/107208, but I don't know the exact address of the tarball. I could download by clicking the button in the page, but I couldn't via wget. >> Tools/ChangeLog:16 >> + * gtk/patches/jxrlib-bug748590.patch: Added. Minor build fix. > > The debian version doesn't build? or is this a debian patch? This is a debian patch. >> Tools/ChangeLog:18 >> + Only Makefie is provided, but it does not fit jhbuild system for webkitgtk. Fortunately any debian > > Really? Isn't there any other serious alternative to jxrlib? No alternative as long as I know. I guess that's why debian developer wrote the usecmake.patch :P The original Makefile from MS really sucks. >> Tools/gtk/jhbuildrc:23 >> +jhbuildrc_common.init(globals(), "gtk") > > What is this change about? Removed a tailing white space. >> Tools/gtk/patches/jxrlib-bug748590.patch:3 >> +Origin: upstream, https://jxrlib.codeplex.com/SourceControl/changeset/04cf339385b8196f98025b43a366a0790deac994 > > I see it's a debian patch now. Yup.
Also relevant may be Chrome (and Mozilla's) rejection: https://code.google.com/p/chromium/issues/detail?id=56908#c27
(In reply to comment #3) > JPEG-XR is patented by Microsoft [1]. > 1. http://en.wikipedia.org/wiki/JPEG_XR#Licensing I think license issue was resolved. In the same section in your link. "In April 2013, Microsoft released an open source JPEG XR library under the BSD licence.[49][50] This resolved any licencing issues with the library being implemented in software packages distributed under popular open source licences such as the GNU General Public License, " > Do you have any examples of web content that uses this format? This sounds I need some time to research. What I can tell now is that jxr image is in the same situation with webp. They're not that popular compared with jpg, png and gif because of browser compatibility. (currently IE is the only browser supporting it.) > Additional image formats impose a burden on > the maintenance of a port because they are common vectors for security > vulnerabilities. I do not think we should add support for formats that have > little or no web content. Yeah. I can understand. > At the very least, this should be discussed on the mailing list before integration into the source tree. O.K I'll email to webkitgtk mailing list. But not today ;) > Also relevant may be Chrome (and Mozilla's) rejection: > https://code.google.com/p/chromium/issues/detail?id=56908#c27 Yes. They rejected. That's why I emailed to webkit mailing list to hear if webkit folks are interested in modern image formats like jxr or webp. https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html
(In reply to comment #7) > > Also relevant may be Chrome (and Mozilla's) rejection: > > https://code.google.com/p/chromium/issues/detail?id=56908#c27 > Yes. They rejected. That's why I emailed to webkit mailing list to hear if > webkit folks are interested in modern image formats like jxr or webp. > https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html That discussion turned into one about how to organize the code though, but not about what image formats were appropriate for WebKit. I think it's important to carefully consider new formats.
Comment on attachment 249826 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249826&action=review >>> Tools/ChangeLog:13 >>> + the correct address where the tarball exists at. We will use jxrlib-1.1 which is almost latest. >> >> This is unfortunate . . . > > Indeed. MS provides us a download site here http://jxrlib.codeplex.com/releases/view/107208, but I don't know the exact address of the tarball. I could download by clicking the button in the page, but I couldn't via wget. You can use git $ git clone https://git01.codeplex.com/jxrlib However there are not tags nor branches on that repository. Maybe checking a specific commit is enough. >>> Tools/ChangeLog:18 >>> + Only Makefie is provided, but it does not fit jhbuild system for webkitgtk. Fortunately any debian >> >> Really? Isn't there any other serious alternative to jxrlib? > > No alternative as long as I know. I guess that's why debian developer wrote the usecmake.patch :P The original Makefile from MS really sucks. FWIW: One of the latest commits on the git repository says "Linux support: Added an install target and generate pkg-config file".
Comment on attachment 249826 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249826&action=review >>>> Tools/ChangeLog:13 >>>> + the correct address where the tarball exists at. We will use jxrlib-1.1 which is almost latest. >>> >>> This is unfortunate . . . >> >> Indeed. MS provides us a download site here http://jxrlib.codeplex.com/releases/view/107208, but I don't know the exact address of the tarball. I could download by clicking the button in the page, but I couldn't via wget. > > You can use git > > $ git clone https://git01.codeplex.com/jxrlib > > However there are not tags nor branches on that repository. Maybe checking a specific commit is enough. Yeah I know and actually tried already. The problem of using git repo is that applying patches is not allowed for git repo (especially for temporal git branch). usecmake.patch is really needed. >>>> Tools/ChangeLog:18 >>>> + Only Makefie is provided, but it does not fit jhbuild system for webkitgtk. Fortunately any debian >>> >>> Really? Isn't there any other serious alternative to jxrlib? >> >> No alternative as long as I know. I guess that's why debian developer wrote the usecmake.patch :P The original Makefile from MS really sucks. > > FWIW: One of the latest commits on the git repository says "Linux support: Added an install target and generate pkg-config file". Yeah. I tried too. It still sucks. I could not pass some essential arguments like prefix and libdir into the Makefile. so it seems not to fit jhbuld.
Created attachment 249959 [details] Patch
(In reply to comment #7) > > Also relevant may be Chrome (and Mozilla's) rejection: > > https://code.google.com/p/chromium/issues/detail?id=56908#c27 > Yes. They rejected. That's why I emailed to webkit mailing list to hear if > webkit folks are interested in modern image formats like jxr or webp. > https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html I think we should not support JPEG-XR for the same reasons Chrome and Firefox are not. Sorry ChangSeok.