Re: unicodesymbols: have several commands for a single symbol?
Am Samstag, dem 19.02.2022 um 02:43 +0100 schrieb Thibaut Cuvelier: > Does it look alright to you? If so, I will push these patches. So if an entry has "", this will be set empty, and if it has nothing, it will inherit the former, right? And until now, only "" was allowed, no missing table entries? I am just asking if I got it right. If so, it looks good to me. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3 and 2.4 have troubles displaying EPS images
I've been back on this issue. I think that slightly changing the call to ImageMagick is the best solution, as it will not break things that used to work and has the potential of enabling preview of images that did not have. What do you think about this (minimalist) patch? On Sun, 13 Feb 2022 at 13:13, Dr Eberhard Lisse wrote: > Thibaut, > > I don't know. Try both of them > > TeX has nothing to do with this, it's a LyX issue. > > el > > On 2022-02-10 03:22 , Thibaut Cuvelier wrote: > > On Wed, 9 Feb 2022 at 22:45, Dr Eberhard Lisse wrote: > > > > Is the issue displaying it on the screen or in the resulting PDF? > > > > > > For me, only the preview in LyX: LaTeX handles the EPS without troubles. > > > > Try GraphicsMagick :-)-O > > > > > > Isn't there a difference in the number of supported formats? Both are > > quite copious (https://imagemagick.org/script/formats.php#supported > > vs. http://www.graphicsmagick.org/formats.html, I'm not sure there's > > any noticeable difference for a LyX user. > > > > Digging deeper into Photoshop's behaviour, it seems that the TIFF > > portion is a low-quality preview of the actual content (by default, > > using only one bit per pixel). Among the two images output by > > ImageMagick (with a simple magick $$i.eps $$o.png), the preview is the > > second file ($$o-1.png), while the expected one is the first > > ($$o-0.png). > > > > As I understand, the standard behaviour with pdflatex is to go through > > epstopdf, which internally uses GhostScript. It doesn't care about > > the preview and only outputs the image that corresponds to > > ImageMagick's $$o-0.png. > > > > (However, I'm really unfamiliar with TeX and derivatives' code source, > > so I could not really triple check this.) > > > 0005-configure-for-EPS-to-PNG-ask-ImageMagick-to-only-con.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: unicodesymbols: have several commands for a single symbol?
Hi all, Here is an implementation of the mechanism discussed here. I split the largest part of the patch into two parts: adding the possibility to store several characters in CharInfo, then parsing the new lines (with just two new entries in unicodesymbols). These patches also change the names of several methods and variables to bring them to uniformity with newer code (with camel case). Then, I had to patch Encodings::fromLaTeXCommand for the new entries to be used: that code matches entries by looking up prefixes of the entered LaTeX code until there is a match. The problem is with !`, because ! is a match. Hence, I added a simple check: if the whole command corresponds to an entry in unicodesymbols, use that; that doesn't fix the global issue (that would have to be the longest prefix that matches), but it would be much more complex to do and the added value seems lower to me. Does it look alright to you? If so, I will push these patches. On Mon, 14 Feb 2022 at 06:59, Jürgen Spitzmüller wrote: > Am Montag, dem 14.02.2022 um 03:24 +0100 schrieb Thibaut Cuvelier: > > Thanks, I just did that (with a small test file): a460097823. > > > > However, this test showed a limitation in the current unicodesymbols: > > there can be only one LaTeX command per symbol. This is a limitation > > in only a few cases, like LyX Document > > \textexclamdown and !`: both of them are mapped to ¡ (i.e. ), > > but the file only allows for one mapping. > > Yes, this stems from the history of this file, which has been created > first only for the unicode to latex route. > > > If we decide to solve this problem, we could have several solutions > > (all modifying Encodings::read), I could think of two: > > - either use a separator symbol in the latexcommand part of each > > unicodesymbols line, but it would be hard to find a single character > > that is never used for latexcommands > > yes. > > > - or have multiple lines for a single character, with duplicate > > information for the second one or a simpler line format for these > > entries. For instance, for the inverted exclamation mark: > > > > 0x00a1 "\\textexclamdown" "" "force=cp862;cp1255;euc-jp;euc- > > jp-platex;euc-kr;utf8-platex" # INVERTED EXCLAMATION MARK > > 0x00a1 "!`" # Implicitly, all the other parameters still apply > > I'd also prefer this. For LaTeX output, the first occurrence should be > preferred. > > > What do you think of this? Should this be done? > > I think it's definitely useful. > > Jürgen > > 0002-unicodesymbols-parse-supplementary-lines-to-encode-a.patch Description: Binary data 0003-Encodings-fromLaTeXCommand-if-the-command-directly-m.patch Description: Binary data 0001-CharInfo-allow-to-store-several-commands-both-text-a.patch Description: Binary data 0004-unicodesymbols-add-several-synonyms.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Adding a new assertion
In whatever part of LyX's code that marks a buffer as dirty, should we assert that the document is not read-only? If I open the User Guide from the Help menu, editing is disabled. But if I run: command-sequence inset-forall Caption char-delete-forward; statistics; undo The buffer is marked as dirty. I'm not sure if something actually changed, but I wonder if a general way to catch these types of issues is to add an assertion. But perhaps there are some cases where it is hard to know if the buffer is dirty (maybe with Undo?) so we mark it as dirty just in case? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Assertion from command-sequence
To reproduce, open the User Guide (make sure it is editable, i.e., not read only). Then run the following command sequence: command-sequence inset-forall Caption char-delete-forward; statistics; undo I get the following assertion: CursorSlice.cpp (222): can't compare cursor and anchor in different insets p: inset: 0x55bfc93571e0 idx: 0 par: 1 pos: 0 q: inset: 0x55bfc9f0d290 idx: 0 par: 0 pos: 0 support/lassert.cpp (52): ASSERTION false VIOLATED IN /home/scott/lyxbuilds/master-master/repo/src/CursorSlice.cpp:225 Can someone reproduce? Adding "force" after char-delete-forward in the command-sequence causes there to be no assertion. I don't think it's important, but just for background information, this command-sequence came from here: https://tex.stackexchange.com/questions/110690/word-count-in-lyx-which-does-not-include-figure-captions/110707?noredirect=1#comment1580098_110707 Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Advanced find does not search in deactivated branches
Le 18/02/2022 à 10:31, Kornel Benko a écrit : Given the string 'ABCD' while 'B' is in deactivated branch. Now considering the case searching for the word 'ACD'. Should it be found? This is a case for change tracking IMO. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Advanced find does not search in deactivated branches
Am Freitag, dem 18.02.2022 um 10:31 +0100 schrieb Kornel Benko: > Given the string 'ABCD' while 'B' is in deactivated branch. > Now considering the case searching for the word 'ACD'. > Should it be found? Don't know. But if a deactivated branch (or note) contains one or several paragraphs, strings there should be found. This seems to be the more common use case (or at least how I use branches more commonly). Thus I'd make that optional. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Advanced find does not search in deactivated branches
Am Thu, 17 Feb 2022 16:44:18 -0500 schrieb Scott Kostyshak : > On Thu, Feb 17, 2022 at 03:02:00PM +0100, Kornel Benko wrote: > > Am Thu, 17 Feb 2022 07:55:10 -0500 > > schrieb Scott Kostyshak : > > > > > In the attached, if I do an advanced find with 2.4.04dev for $\coloneqq$, > > > it is not > > > found. If I then activate the branch, it is found. Is this a feature or a > > > bug? > > > > > > Scott > > > > Feature, since exported latex does not contain these data, and we use > > latex output as a search-source. > > Ah that makes sense. Indeed now I see that even LyX notes aren't > searched. > > It feels a bit strange from a user perspective though since vanilla find > does search in deactivated branches. Also, the user does not know the > implementation (i.e., searching the LaTeX output). That said, it sounds > like it would be complicated to ask for LaTeX output from all insets. > > Scott Given the string 'ABCD' while 'B' is in deactivated branch. Now considering the case searching for the word 'ACD'. Should it be found? Kornel pgphtfOCSOgCW.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
