Re: LyX 2.3.0 Ubuntu possible bug with custom file format
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
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
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 Heckwrote: > > 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
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
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
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
Re: coding of text
Wolfgang, I usually put it into a listings environment, with slightly smaller text size and in typewriter but can not recall having an issue. On 2018-03-22 14:16 , Wolfgang Engelmann wrote: > > Am 22.03.2018 um 13:19 schrieb José Abílio Matos: >> >> On Wednesday, 21 March 2018 19.17.12 WET Wolfgang Engelmann wrote: >> >> > Thanks again, Paul, it was us-ascii coded and >> >> > iconv -f us-ascii -t utf-8 original-us-ascii.txt > converted-utf8.txt >> >> > worked fine. >> >> > Wolfgang >> >> >> >> If the encoding was us-ascii there is no need to to a conversion since >> ascii is a subset of utf-8. >> >> -- >> >> José Abílio >> > But the charset of us-ascii appeared in my LyX notes differently from > the document text. In the meantime I found out that text editors (e.g. > kwrite) offer exports in various charsets such as utf-8. > Wolfgang
Re: coding of text
Am 22.03.2018 um 13:19 schrieb José Abílio Matos: On Wednesday, 21 March 2018 19.17.12 WET Wolfgang Engelmann wrote: > Thanks again, Paul, it was us-ascii coded and > iconv -f us-ascii -t utf-8 original-us-ascii.txt > converted-utf8.txt > worked fine. > Wolfgang If the encoding was us-ascii there is no need to to a conversion since ascii is a subset of utf-8. -- José Abílio But the charset of us-ascii appeared in my LyX notes differently from the document text. In the meantime I found out that text editors (e.g. kwrite) offer exports in various charsets such as utf-8. Wolfgang
Re: coding of text
On Wednesday, 21 March 2018 19.17.12 WET Wolfgang Engelmann wrote: > Thanks again, Paul, it was us-ascii coded and > iconv -f us-ascii -t utf-8 original-us-ascii.txt > converted- utf8.txt > worked fine. > Wolfgang If the encoding was us-ascii there is no need to to a conversion since ascii is a subset of utf-8. -- José Abílio