Re: LyX 2.3.0 Ubuntu possible bug with custom file format

2018-03-22 Thread Scott Kostyshak 
On Thu, Mar 22, 2018 at 09:52:27PM +, Richard Kimberly Heck wrote:

> That's a reasonable suggestion. I'd suggest you file a bug report making it.

Ticket was reported here:

https://www.lyx.org/trac/ticket/11087

Scott


signature.asc
Description: PGP signature

Re: LyX 2.3.0 Ubuntu possible bug with custom file format

2018-03-22 Thread Richard Kimberly Heck 
On 03/22/2018 05:13 PM, Cris Fuhrman wrote:
> My initial response was only to Riki. This one is to the whole list
> (slightly clarified):
>
> On Thu, Mar 22, 2018 at 2:36 PM, Richard Kimberly
> Heck > wrote:
>
>
> It looks to me as if maybe there is a difference between 2.2.x and
> 2.3.0 in whether
> it was packed with the "magic" mime-type library. The
> magic-related code seems to have been
> skipped in the 2.2.x version.
>
> In any event, this looks like a bug in the magic library. That's
> where we are getting the
> file type from.
>
>
> For the record, the particular .plantuml file *could* be a html_table,
> because it has HTML table data embedded in it. So, I'm not sure I'd
> call it a bug in that library. It's trying to guess, and it's doing a
> pretty good job.
>
> The bug (to me) is that LyX is giving priority to the magic detection
> (guessing) over the actual filetype, defeating the rule. 
>
> I would think that it should trust filetypes that have defined rules
> first, then use magic if it doesn't know the file type.

That's a reasonable suggestion. I'd suggest you file a bug report making it.

Riki

Re: LyX 2.3.0 Ubuntu possible bug with custom file format

2018-03-22 Thread Cris Fuhrman 
My initial response was only to Riki. This one is to the whole list
(slightly clarified):

On Thu, Mar 22, 2018 at 2:36 PM, Richard Kimberly Heck 
wrote:

>
> It looks to me as if maybe there is a difference between 2.2.x and 2.3.0
> in whether
> it was packed with the "magic" mime-type library. The magic-related code
> seems to have been
> skipped in the 2.2.x version.
>
> In any event, this looks like a bug in the magic library. That's where we
> are getting the
> file type from.
>

For the record, the particular .plantuml file *could* be a html_table,
because it has HTML table data embedded in it. So, I'm not sure I'd call it
a bug in that library. It's trying to guess, and it's doing a pretty good
job.

The bug (to me) is that LyX is giving priority to the magic detection
(guessing) over the actual filetype, defeating the rule.

I would think that it should trust filetypes that have defined rules first,
then use magic if it doesn't know the file type.

Cheers,

C. Fuhrman

Re: LyX 2.3.0 Ubuntu possible bug with custom file format

2018-03-22 Thread Paul A. Rubin 

On 03/22/2018 01:53 PM, Cris Fuhrman wrote:
I'm testing 2.3.0 on my Ubuntu VM (didn't want to break my Windows 
install) with a document that has a lot of PlantUML files (which have 
a custom conversion rule to SVG that works well most of the time).


One of the files has some embedded HTML in it, and LyX seems to decide 
(despite the .plantuml extension and conversion rule) to process it 
has an html_table extension.


I tracked down the log messages whenever I try to reload the image. 
Note the fact that it gets some mime type of *text/html* and having 
determined the content, it ignores the extension (and thus the rule). 
This seems like a bug.


13:38:01.770: (graphics-reload)graphics/GraphicsCacheItem.cpp
(421): Converting it to  format.
graphics/GraphicsCacheItem.cpp (391):
[CacheItem::Impl::convertToDisplayFormat]
Attempting to convert image file:
/home/cfuhrman/Documents/mgl843-notes-de-cours/figures/RFC_example.plantuml
with displayed filename:
~/Documents/mgl843-notes-de-cours/figures/RFC_example.plantuml
Format.cpp (438): got format from MIME type: text/html -> html_table


Here's what a successful reload of a .plantuml image reloads as. 
You'll note that the *getFormatFromContents* first fails before it 
uses the file extension:


13:47:50.702: (graphics-reload)graphics/GraphicsCacheItem.cpp
(421): Converting it to  format.
graphics/GraphicsCacheItem.cpp (391):
[CacheItem::Impl::convertToDisplayFormat]
Attempting to convert image file:
/home/cfuhrman/Documents/mgl843-notes-de-cours/figures/RFC_class.plantuml
with displayed filename:
~/Documents/mgl843-notes-de-cours/figures/RFC_class.plantuml
Format.cpp (389): filetools(getFormatFromContents)
File type not recognised before EOF!
Format.cpp (396): filetools(getFormatFromContents)
Couldn't find a known format!
Format.cpp (507): will guess format from file extension: plantuml
-> PlantUML
graphics/GraphicsCacheItem.cpp (398):
The file contains PlantUML format data.
graphics/GraphicsCacheItem.cpp (347): Unable to convert from
PlantUML to bmp
graphics/GraphicsCacheItem.cpp (347): Unable to convert from
PlantUML to gif
graphics/GraphicsCacheItem.cpp (347): Unable to convert from
PlantUML to jpg
graphics/GraphicsCacheItem.cpp (347): Unable to convert from
PlantUML to pbm
graphics/GraphicsCacheItem.cpp (347): Unable to convert from
PlantUML to pgm
graphics/GraphicsCacheItem.cpp (410): No conversion needed (file
in file cache)!
graphics/GraphicsCacheItem.cpp (301): Loading image.
graphics/GraphicsCacheItem.cpp (307): Image loading succeeded.


Is this a bug or a feature? How can I force LyX not to try to be smart 
about the file content? This problem didn't happen on Windows 10 with 
2.2.x.


Cheers,

C. Fuhrman
Do you have a custom MIME type set for .plantuml in the Ubuntu VM? You 
might try "xdg-mime query filetype RFC_class.plantuml" to see what the 
system thinks it is.


Paul

Re: LyX 2.3.0 Ubuntu possible bug with custom file format

2018-03-22 Thread Richard Kimberly Heck 
On 03/22/2018 01:53 PM, Cris Fuhrman wrote:
> I'm testing 2.3.0 on my Ubuntu VM (didn't want to break my Windows
> install) with a document that has a lot of PlantUML files (which have
> a custom conversion rule to SVG that works well most of the time).
>
> One of the files has some embedded HTML in it, and LyX seems to decide
> (despite the .plantuml extension and conversion rule) to process it
> has an html_table extension.
>
> I tracked down the log messages whenever I try to reload the image.
> Note the fact that it gets some mime type of *text/html* and having
> determined the content, it ignores the extension (and thus the rule).
> This seems like a bug.
>
> 13:38:01.770: (graphics-reload)graphics/GraphicsCacheItem.cpp
> (421): Converting it to  format.
> graphics/GraphicsCacheItem.cpp (391):
> [CacheItem::Impl::convertToDisplayFormat]
> Attempting to convert image file:
> 
> /home/cfuhrman/Documents/mgl843-notes-de-cours/figures/RFC_example.plantuml
> with displayed filename:
> ~/Documents/mgl843-notes-de-cours/figures/RFC_example.plantuml
> Format.cpp (438): got format from MIME type: text/html -> html_table
>
>
> Here's what a successful reload of a .plantuml image reloads as.
> You'll note that the *getFormatFromContents* first fails before it
> uses the file extension:
>
> 13:47:50.702: (graphics-reload)graphics/GraphicsCacheItem.cpp
> (421): Converting it to  format.
> graphics/GraphicsCacheItem.cpp (391):
> [CacheItem::Impl::convertToDisplayFormat]
> Attempting to convert image file:
> /home/cfuhrman/Documents/mgl843-notes-de-cours/figures/RFC_class.plantuml
> with displayed filename:
> ~/Documents/mgl843-notes-de-cours/figures/RFC_class.plantuml
> Format.cpp (389): filetools(getFormatFromContents)
> File type not recognised before EOF!
> Format.cpp (396): filetools(getFormatFromContents)
> Couldn't find a known format!
> Format.cpp (507): will guess format from file extension: plantuml
> -> PlantUML
> graphics/GraphicsCacheItem.cpp (398): 
> The file contains PlantUML format data.
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from
> PlantUML to bmp
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from
> PlantUML to gif
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from
> PlantUML to jpg
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from
> PlantUML to pbm
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from
> PlantUML to pgm
> graphics/GraphicsCacheItem.cpp (410): No conversion needed (file
> in file cache)!
> graphics/GraphicsCacheItem.cpp (301): Loading image.
> graphics/GraphicsCacheItem.cpp (307): Image loading succeeded.
>
>
> Is this a bug or a feature? How can I force LyX not to try to be smart
> about the file content? This problem didn't happen on Windows 10 with
> 2.2.x.

Hard to say. It looks to me as if maybe there is a difference between
2.2.x and 2.3.0 in whether
it was packed with the "magic" mime-type library. The magic-related code
seems to have been
skipped in the 2.2.x version.

In any event, this looks like a bug in the magic library. That's where
we are getting the
file type from.

How to avoid it? That I do not know.

Riki

LyX 2.3.0 Ubuntu possible bug with custom file format

2018-03-22 Thread Cris Fuhrman 
I'm testing 2.3.0 on my Ubuntu VM (didn't want to break my Windows install)
with a document that has a lot of PlantUML files (which have a custom
conversion rule to SVG that works well most of the time).

One of the files has some embedded HTML in it, and LyX seems to decide
(despite the .plantuml extension and conversion rule) to process it has an
html_table extension.

I tracked down the log messages whenever I try to reload the image. Note
the fact that it gets some mime type of *text/html* and having determined
the content, it ignores the extension (and thus the rule). This seems like
a bug.

13:38:01.770: (graphics-reload)graphics/GraphicsCacheItem.cpp (421): Converting
> it to  format.
> graphics/GraphicsCacheItem.cpp (391):
> [CacheItem::Impl::convertToDisplayFormat]
> Attempting to convert image file:
> /home/cfuhrman/Documents/mgl843-notes-de-cours/figures/RFC_example.plantuml
> with displayed filename:
> ~/Documents/mgl843-notes-de-cours/figures/RFC_example.plantuml
> Format.cpp (438): got format from MIME type: text/html -> html_table


Here's what a successful reload of a .plantuml image reloads as. You'll
note that the *getFormatFromContents* first fails before it uses the file
extension:

13:47:50.702: (graphics-reload)graphics/GraphicsCacheItem.cpp (421): Converting
> it to  format.
> graphics/GraphicsCacheItem.cpp (391):
> [CacheItem::Impl::convertToDisplayFormat]
> Attempting to convert image file:
> /home/cfuhrman/Documents/mgl843-notes-de-cours/figures/RFC_class.plantuml
> with displayed filename:
> ~/Documents/mgl843-notes-de-cours/figures/RFC_class.plantuml
> Format.cpp (389): filetools(getFormatFromContents)
> File type not recognised before EOF!
> Format.cpp (396): filetools(getFormatFromContents)
> Couldn't find a known format!
> Format.cpp (507): will guess format from file extension: plantuml ->
> PlantUML
> graphics/GraphicsCacheItem.cpp (398):
> The file contains PlantUML format data.
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from PlantUML to
> bmp
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from PlantUML to
> gif
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from PlantUML to
> jpg
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from PlantUML to
> pbm
> graphics/GraphicsCacheItem.cpp (347): Unable to convert from PlantUML to
> pgm
> graphics/GraphicsCacheItem.cpp (410): No conversion needed (file in file
> cache)!
> graphics/GraphicsCacheItem.cpp (301): Loading image.
> graphics/GraphicsCacheItem.cpp (307): Image loading succeeded.


Is this a bug or a feature? How can I force LyX not to try to be smart
about the file content? This problem didn't happen on Windows 10 with 2.2.x.

Cheers,

C. Fuhrman