Bug 143265 – [GTK] Add jxrlib as a dependency to the jhbuild module set

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[ChangSeok Oh]

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

[ChangSeok Oh]

Created attachment 249826 [details]
Patch

[Carlos Garcia Campos]

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 <[e-mail]>
> +Origin: upstream, https://jxrlib.codeplex.com/SourceControl/changeset/04cf339385b8196f98025b43a366a0790deac994

I see it's a debian patch now.

[Martin Robinson]

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

[Martin Robinson]

At the very least, this should be discussed on the mailing list before integration into the source tree.

[ChangSeok Oh]

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.

[Martin Robinson]

Also relevant may be Chrome (and Mozilla's) rejection: https://code.google.com/p/chromium/issues/detail?id=56908#c27

[ChangSeok Oh]

(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

[Martin Robinson]

(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.

[Carlos Alberto Lopez Perez]

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".

[ChangSeok Oh]

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.

[ChangSeok Oh]

Created attachment 249959 [details]
Patch

[Michael Catanzaro]

(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.