Menu
▾
▴
#283 When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
Description of problem:
For some time, a new mime type was added to differentiate a DjVu image from a DjVu multi-page document, if an application requires djvulibre-libs like Evince, there are no problems, however, when installing the DjVuLibre package the mime types change and a multi-page document is not recognized correctly, therefore Evince will no longer open the document by its new criteria of exclusion.
In addition to solve the problem, we must eliminate the new mime types added and update the database manually, something unintuitive for the common user.
Version-Release number of selected component:
Fedora Workstation 27 beta
Gnome 3.26.1
Evince 3.26
djvulibre 3.5.27 (4.fc27)
How reproducible:
Always
Steps to Reproduce:
- Install Evince and djvu backend (evince-djvu package)
- View a multi-page djvu document with evince
- Install the djvulibre package
- View a multi-page djvu document with evince
Actual results:
After installing the djvulibre package, Evince refuses to open the document when it is recognized as a djvu image instead of a multipage document.
Expected results:
After installing the djvulibre package, don't overwrite the mime types or use the same distinction. Otherwise, at least when the package is uninstalled, the database is updated and the change is reversed.
Cheers
Related
Why are the evince people messing up with a registered mime type?
https://www.iana.org/assignments/media-types/image/vnd-djvu
In their diff they claim that they've waited one year and that it should be okay...
This is not their decision!!!
Even if they want to use this method to force single page documents into nautilus instead of evince, they should probably do the opposite (image/vnd.djvu+singlepage).
I'm the shared-mime-info maintainer.
Why do you ship a mime-type file for djvu when there's been one in shared-mime-info since 2002? Even if the one in shared-mime-info was inaccurate, why not contribute to shared-mime-info instead of providing a mime-type that conflicts with shared-mime-info?
FWIW, image/vnd.djvu+multipage is a sub-class-of image/vnd.djvu, so a multi-page DjVu document is both image/vnd.djvu and image/vnd.djvu+multipage. Unless somebody overwrites the mime-type, which is what the file you ship in djvulibre is doing.
Feel free to file a bug at:
https://bugs.freedesktop.org/enter_bug.cgi?product=shared-mime-info
if there's something that needs to be changed in shared-mime-info. I think the problem lies with a misunderstanding as to how shared-mime-info works. We have a concept of inheritance that isn't possible in "standard" mime-type systems.
There are several things going on here.
The first one is the meaning of image/vnd.djvu. This was defined in 2002 with IANA. There are many things one could complain about. In retrospect, was it a good idea to make it a subtype of image? Probably not. But this is now irrelevant.
The second one is knowing which mime types are coming with the shared-mime-type package and which ones are not. Otherwise why would the shared mime data spec allow for packagers to define mime types? One sensible way could be to say that all registered types (https://www.iana.org/assignments/media-types/media-types.xhtml) should come preinstalled. But that’s a lot of things to maintain.
Absent such a rule, one must define what is happening when an application registers another instance of an existing mime type:
Which one is selected? I guess this is why there are priority numbers in the magic section. I just checked in git that the freedesktop.xml entries for djvu have priority 80. Mine have priority 50 (the default according to the spec). Why are mine selected? Are there priority guidelines (in the end I just mean my files to be used when no other definition exists…)
How does inheritance work when it comes to magic sections? You say that a FORMDJVM file is both a vnd.djvu and vnd.djvu+multipage, whereas a FORMDJVU file is only vnd.djvu. Shouldn’t the magic section of the file that defines vnd.djvu match all files that are vnd.djvu instead of excluding those that are also in a subclass? One of the principle of inheritance is that the superclass code should not need to be changed when one defines a subclass. If this were the case, we would not have a problem.
I still believe that there is a case to make for subclassing the other way around, that is with image/vnd.djvu+singlepage as a subclass of image/vnd.djvu. I say this because I believe that a program that claims to understand files of type image/vnd.djvu should be able to understand both single page and multipage files, whereas a program that only claims to understand image/vnd.djvu+singlepage does not claim it understand multipage files. Now I can also see that nautilus probably claims all the image/* files, even though it certainly does not understand them all. This is a contravariance problem…
Here is what I will do:
I will reduce the priority in djvulibre.xml to 30, with the idea that the defaults provided by the shared-mime-type package should be 50.
Packagers might decide to completely drop djvulibre.xml if the want.
I will add vnd.djvu+multipage in the file djvulibre-djview4.desktop because I believe that people who install djview mean to use it for both single page and multipage files. I wish things were subclassed the other way around.
I believe you could reconsider this story of magic sections that need to be aware of all the subclasses. Also clarify the spec with guidelines for magic priorities (i.e. more than 50 means override default files provided by shared-mime, less then 50 means prefer the default files), and with the covariance/contravariance aspects of subclassing…
Best,
Leon
From: Bastien Nocera hadess@users.sourceforge.net
Reply-To: "[djvu:bugs]" 283@bugs.djvu.p.re.sourceforge.net
Date: Wednesday, April 18, 2018 at 8:12 PM
To: "[djvu:bugs]" 283@bugs.djvu.p.re.sourceforge.net
Subject: [djvu:bugs] Re: #283 When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
Why are the evince people messing up with a registered mime type?
I'm the shared-mime-info maintainer.
In their diff they claim that they've waited one year and that it should be okay...
This is not their decision!!!
Why do you ship a mime-type file for djvu when there's been one in shared-mime-info since 2002? Even if the one in shared-mime-info was inaccurate, why not contribute to shared-mime-info instead of providing a mime-type that conflicts with shared-mime-info?
FWIW, image/vnd.djvu+multipage is a sub-class-of image/vnd.djvu, so a multi-page DjVu document is both image/vnd.djvu and image/vnd.djvu+multipage. Unless somebody overwrites the mime-type, which is what the file you ship in djvulibre is doing.
Feel free to file a bug at:
https://bugs.freedesktop.org/enter_bug.cgi?product=shared-mime-info
if there's something that needs to be changed in shared-mime-info. I think the problem lies with a misunderstanding as to how shared-mime-info works. We have a concept of inheritance that isn't possible in "standard" mime-type systems.
[bugs:#283] When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
Status: wont-fix
Group: djvulibre
Labels: Linux
Created: Sat Nov 04, 2017 07:27 AM UTC by Bastián Díaz
Last Updated: Wed Apr 18, 2018 10:44 PM UTC
Owner: nobody
Description of problem:
For some time, a new mime type was added to differentiate a DjVu image from a DjVu multi-page document, if an application requires djvulibre-libs like Evince, there are no problems, however, when installing the DjVuLibre package the mime types change and a multi-page document is not recognized correctly, therefore Evince will no longer open the document by its new criteria of exclusion.
In addition to solve the problem, we must eliminate the new mime types added and update the database manually, something unintuitive for the common user.
Version-Release number of selected component:
Fedora Workstation 27 beta
Gnome 3.26.1
Evince 3.26
djvulibre 3.5.27 (4.fc27)
How reproducible:
Always
Steps to Reproduce:
Install Evince and djvu backend (evince-djvu package)
View a multi-page djvu document with evince
Install the djvulibre package
View a multi-page djvu document with evince
Actual results:
After installing the djvulibre package, Evince refuses to open the document when it is recognized as a djvu image instead of a multipage document.
Expected results:
After installing the djvulibre package, don't overwrite the mime types or use the same distinction. Otherwise, at least when the package is uninstalled, the database is updated and the change is reversed.
Cheers
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/283/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#283I really don't see the point of discussing how shared-mime-info is implemented which seems to be the main point of the comment.
Priority doesn't work as you think, priority applies to the magic not the mime-type, which is why it's an attribute of the magic element not of the mime-type:
"
magic elements contain a list of match elements, any of which may match, and an optional priority attribute for all of the contained rules.
"
Depending on which order the files in /usr/share/mime/packages your DjVu XML file will simply overwrite the mime-type definition shipped in shared-mime-info.
About which mime-types we ship, we do not regress or remove mime-types. The DjVu mime-type has been defined in shared-mime-info since 2002. It won't be removed.
The inheritance doesn't work because you overwrite the mime-type defined by freedesktop.org.xml, and lose the inheritance in the process.
You also shouldn't be defining your own icon, it's the purview of icon themes.
On Tuesday, April 24, 2018 9:13:38 AM EDT Bastien Nocera wrote:
The point is that I am trying to understand what is the right thing to do. In my world raising one's voice is not an argument. This is why I rethought my first reaction to the bug (which was not well thought), wrote the message that you say is pointless, and decided that it would be wise to start by lowering the priority.
This is indeed what I understood. By doing so I can give people the choice of getting my icons and translations instead of the default one (configure --disable-desktopfiles has been around for ages) and I am doing so without damaging the detection of the subclassed types. I was hoping the other entries (translations, etc) were merged, but I can see that one has to choose only one name.
I did not ask for this. I made a comment about the inheritance process as a mere suggestion (not even a bug report.)
And this is why I am returning to the design of the shared mime type info. The spec says " This specification proposes: A standard way for applications to install new MIME related information. etc..." and explains how to do it. This what I did. Maybe the spec should say that the prototypical implementation (yours) comes with a list of mime types that one should avoid tweaking those using the process explained in the spec. What about other implementations of the spec (are there any to start with? is the spec intended to make this possible?)
Anyway, got to go. I will attract the attention of the packagers on this thread so that they can decide whether to use --disable-desktopfiles or not.
Why is the installation of mime-types definitions controlled by "--disable-desktopfiles"?
shared-mime-info isn't my implementation, it's the reference (and only) implementation from Freedesktop.org, the same loosely knit group of developers that wrote the shared mime info spec. I just took over maintenance of the mime definitions in 2004 because I was adding so many entries for video and audio types.
Why is the installation of mime-types definitions controlled by "--disable-desktopfiles"?
Because there are plenty of OS for which this does not make sense.
The subdir desktopfiles contains resources useful for desktop environments, including scalable icons and the controversial mime type decls. What to do with them is very OS dependent. I still believe sad to lose the scalable djvu icon on unix platforms. I first was under the impression that it was enough to install it into hicolor (the default scheme) with the name “image-vnd-djvu.{png,svgz}” but never could have it be recognized by naming alone. My solution was to add the icon name in the mime type spec.
Do you know who could say what is the right way to achieve this? Would that be to add something line Icon=image-vnd-djvu in the official freedesktop xml file? Or something else?
Leon
From: Bastien Nocera hadess@users.sourceforge.net
Reply-To: "[djvu:bugs]" 283@bugs.djvu.p.re.sourceforge.net
Date: Tuesday, April 24, 2018 at 9:56 AM
To: "[djvu:bugs]" 283@bugs.djvu.p.re.sourceforge.net
Subject: [djvu:bugs] Re: #283 When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
Why is the installation of mime-types definitions controlled by "--disable-desktopfiles"?
shared-mime-info isn't my implementation, it's the reference (and only) implementation from Freedesktop.org, the same loosely knit group of developers that wrote the shared mime info spec. I just took over maintenance of the mime definitions in 2004 because I was adding so many entries for video and audio types.
[bugs:#283] When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
Status: closed
Group: djvulibre
Labels: Linux
Created: Sat Nov 04, 2017 07:27 AM UTC by Bastián Díaz
Last Updated: Sun Apr 22, 2018 07:04 PM UTC
Owner: nobody
Description of problem:
For some time, a new mime type was added to differentiate a DjVu image from a DjVu multi-page document, if an application requires djvulibre-libs like Evince, there are no problems, however, when installing the DjVuLibre package the mime types change and a multi-page document is not recognized correctly, therefore Evince will no longer open the document by its new criteria of exclusion.
In addition to solve the problem, we must eliminate the new mime types added and update the database manually, something unintuitive for the common user.
Version-Release number of selected component:
Fedora Workstation 27 beta
Gnome 3.26.1
Evince 3.26
djvulibre 3.5.27 (4.fc27)
How reproducible:
Always
Steps to Reproduce:
Install Evince and djvu backend (evince-djvu package)
View a multi-page djvu document with evince
Install the djvulibre package
View a multi-page djvu document with evince
Actual results:
After installing the djvulibre package, Evince refuses to open the document when it is recognized as a djvu image instead of a multipage document.
Expected results:
After installing the djvulibre package, don't overwrite the mime types or use the same distinction. Otherwise, at least when the package is uninstalled, the database is updated and the change is reversed.
Cheers
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/283/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#283I first was under the impression that it was enough to install it into hicolor (the default scheme) with the name “image-vnd-djvu.{png,svgz}” but never could have it be recognized by naming alone. My solution was to add the icon name in the mime type spec.
The icon name start with image-vnd.djvu, not image-vnd-djvu:
"icon elements specify the icon to be used for this particular mime-type, given by the name attribute. Generally the icon used for a mimetype is created based on the mime-type by mapping "/" characters to "-"[...]"
FWIW, the icon is not as useful as you might think. Modern desktop environments will thumbnail the DjVu files, and your icon won't match the style of the themes used in most environments.
I would advise against installing it, but in case you still want to, those are the filenames to use.
Ok. I’ll try again.
L.
From: Bastien Nocera hadess@users.sourceforge.net
Reply-To: "[djvu:bugs]" 283@bugs.djvu.p.re.sourceforge.net
Date: Wednesday, April 25, 2018 at 6:12 AM
To: "[djvu:bugs]" 283@bugs.djvu.p.re.sourceforge.net
Subject: [djvu:bugs] Re: #283 When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
I first was under the impression that it was enough to install it into hicolor (the default scheme) with the name “image-vnd-djvu.{png,svgz}” but never could have it be recognized by naming alone. My solution was to add the icon name in the mime type spec.
The icon name start with image-vnd.djvu, not image-vnd-djvu:
"icon elements specify the icon to be used for this particular mime-type, given by the name attribute. Generally the icon used for a mimetype is created based on the mime-type by mapping "/" characters to "-"[...]"
FWIW, the icon is not as useful as you might think. Modern desktop environments will thumbnail the DjVu files, and your icon won't match the style of the themes used in most environments.
I would advise against installing it, but in case you still want to, those are the filenames to use.
[bugs:#283] When installing the DjVuLibre package, install wrong mime type definition and don't update mime database
Status: closed
Group: djvulibre
Labels: Linux
Created: Sat Nov 04, 2017 07:27 AM UTC by Bastián Díaz
Last Updated: Sun Apr 22, 2018 07:04 PM UTC
Owner: nobody
Description of problem:
For some time, a new mime type was added to differentiate a DjVu image from a DjVu multi-page document, if an application requires djvulibre-libs like Evince, there are no problems, however, when installing the DjVuLibre package the mime types change and a multi-page document is not recognized correctly, therefore Evince will no longer open the document by its new criteria of exclusion.
In addition to solve the problem, we must eliminate the new mime types added and update the database manually, something unintuitive for the common user.
Version-Release number of selected component:
Fedora Workstation 27 beta
Gnome 3.26.1
Evince 3.26
djvulibre 3.5.27 (4.fc27)
How reproducible:
Always
Steps to Reproduce:
Install Evince and djvu backend (evince-djvu package)
View a multi-page djvu document with evince
Install the djvulibre package
View a multi-page djvu document with evince
Actual results:
After installing the djvulibre package, Evince refuses to open the document when it is recognized as a djvu image instead of a multipage document.
Expected results:
After installing the djvulibre package, don't overwrite the mime types or use the same distinction. Otherwise, at least when the package is uninstalled, the database is updated and the change is reversed.
Cheers
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/283/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#283About the question of "what's the point of allowing to define mime-types", it's used for defining new mime-types, rather than overwriting ones that have been defined for 16 years.
This is what the chemical mime-type project does for example, define mime-types that aren't common enough to live in the shared repository:
https://github.com/dleidert/chemical-mime
On Tuesday, April 24, 2018 9:25:28 AM EDT Bastien Nocera wrote:
I distinguish the spec from the implementation. I am trying to follow the spec because this is what I believe interop specs are for.
Anyway this might be why we discuss:
-- The spec does not say which mime types should be left alone. There is already a difference between IANA registered mime types and other mime types such as the x- ones. Should this be where one draws the line?
-- Also the spec says "A standard way for applications to install new MIME related information. etc..." which is more vague than defining new mime types and that I understood (maybe incorrectly) as including the definition of a default icon, to be possibly overriden by themes. But I agree that this is not as clear as that...
Note again that I am not saying this is a bug in your package. I am just trying to understand what is meant.
Distinguishing the spec and the implementation is rather moot. The implementation is the reference and only implementation that knows how to create a binary cache of mime-types, for various libraries like GLib or Qt to use. Without the reference/only implementation of update-mime-database in shared-mime-info, there's really nothing to be done.
The spec doesn't say which mime types should be left alone because shared-mime-info's freedesktop.org.xml is the "canonical" location for most mime-type definitions.
You'd define your own mime-type in an application or library if either it wasn't suitable for inclusion in shared-mime-info (the HACKING file lists what is suitable: https://cgit.freedesktop.org/xdg/shared-mime-info/tree/HACKING) or you needed the mime-type yesterday for your application to use, and can't wait until shared-mime-info is released and updated. In the latter case, you'd want to make sure that the same definition is used in both cases, and you would remove your own definition when the upstream version is widely deployed.
In your case, you don't need to ship the mime-type definition at all, the "upstream" (the one in shared-mime-info) version will work just fine.
After experimenting with not installing djvulibre-mime.xml, I am reverting to installing it (with lower priority) because this seems to be the only way to associate the djvu icon with djvu files on both kde and gnome...
Following Bastien Nocera's latest email I renamed the djvu icon and removed djvulibre-mime.xml:
https://sourceforge.net/p/djvu/djvulibre-git/ci/16ddfd39070ac6ca26e76feaf2607f5ee57e8edf/
Positive: the djvu icon is well recognized by dolphin.
Negative: it is not recognized by nautilus (default image icon instead).
Since nautilus defaults to previewing, this is not too bad.
But I'd like to know what I am doing wrong...
I have no idea at what level the problem might be, and I really don't have the time to debug it I'm afraid. Your best options is to ask the nautilus developers about it with as much details as possible to allow replicating the problem.
On Thursday, April 26, 2018 10:39:02 AM EDT you wrote:
No time either. As I said, Nautilus gives nice previews by default. One has to work hard to see the (incorrect) icon...
Okay, I'm going to keep the debian djvulibre-desktop package around, without the .xml file, so it basically has nothing but icons. People can install it or not as they choose. Various subsystems can make use of the provided icons (under their new mime-type-consistent names) or not, as they choose. If anyone has a problem with this, please file a bug against the debian package.
Also, I must say that a quick "developer's best practices FAQ regarding desktop issues" would be appreciated. This would be a place to explain how to check if some mime type is already available, when it's appropriate to provide what and when it isn't, etc. These mechanisms are necessarily complicated in order to provide a good user experience across a diversity of environments, but most of the complexity doesn't really need to be groked by developers hooking into them: all they need to know is "provide icons in the following files ..." etc.