Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests
On Sun, Jan 06, 2019 at 07:20:08AM +0100, Kornel Benko wrote: > Am Samstag, 5. Januar 2019 23:38:44 CET schrieb Scott Kostyshak > : > > commit bf65c9fb38e10b0fb06a5be84f2b629073040dfe > > Author: Scott Kostyshak > > Date: Sat Jan 5 17:38:10 2019 -0500 > > > > ctests: invert ko splash lyx22x and lyx23x tests > > > > The Korean splash.lyx is expected to fail with pdflatex. The lyx22x > > and lyx23x tests were not failing before because they were exporting > > to XeTeX with system fonts, which succeeds. After c9e62dec (which > > corrects the export format to the default), the lyx22x and lyx23x > > tests should be inverted. > > > > The change in ko/splash.lyx (see attached) makes the tests pass. > (Provided, the nanumGothic font is installed) > > $ ctest -R ko/splash > Test project /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0 > Start 5759: export/examples/ko/splash_lyx16 > 1/8 Test #5759: export/examples/ko/splash_lyx16 > Passed1.35 sec > Start 5760: export/examples/ko/splash_lyx21 > 2/8 Test #5760: export/examples/ko/splash_lyx21 > Passed1.28 sec > Start 5761: INVERTED.TODO_export/examples/ko/splash_lyx22 > 3/8 Test #5761: INVERTED.TODO_export/examples/ko/splash_lyx22 > ..***Failed6.71 sec > Start 5762: INVERTED.TODO_export/examples/ko/splash_lyx23 > 4/8 Test #5762: INVERTED.TODO_export/examples/ko/splash_lyx23 > ..***Failed6.07 sec > Start 5763: lyx2lyx/examples/ko/splash > 5/8 Test #5763: lyx2lyx/examples/ko/splash . > Passed0.09 sec > Start 5764: check_load/examples/ko/splash > 6/8 Test #5764: check_load/examples/ko/splash .. > Passed0.53 sec > Start 5765: export/examples/ko/splash_xhtml > 7/8 Test #5765: export/examples/ko/splash_xhtml > Passed0.62 sec > Start 5766: DEFAULTOUTPUT_export/examples/ko/splash_pdf4_systemF > 8/8 Test #5766: DEFAULTOUTPUT_export/examples/ko/splash_pdf4_systemF ... > Passed4.80 sec > > 75% tests passed, 2 tests failed out of 8 +1 I'm fine with that since the current splash is not compilable at all by default and since nanumGothic is a free font. Scott signature.asc Description: PGP signature
Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests
Am Samstag, 5. Januar 2019 23:38:44 CET schrieb Scott Kostyshak : > commit bf65c9fb38e10b0fb06a5be84f2b629073040dfe > Author: Scott Kostyshak > Date: Sat Jan 5 17:38:10 2019 -0500 > > ctests: invert ko splash lyx22x and lyx23x tests > > The Korean splash.lyx is expected to fail with pdflatex. The lyx22x > and lyx23x tests were not failing before because they were exporting > to XeTeX with system fonts, which succeeds. After c9e62dec (which > corrects the export format to the default), the lyx22x and lyx23x > tests should be inverted. > The change in ko/splash.lyx (see attached) makes the tests pass. (Provided, the nanumGothic font is installed) $ ctest -R ko/splash Test project /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0 Start 5759: export/examples/ko/splash_lyx16 1/8 Test #5759: export/examples/ko/splash_lyx16 Passed1.35 sec Start 5760: export/examples/ko/splash_lyx21 2/8 Test #5760: export/examples/ko/splash_lyx21 Passed1.28 sec Start 5761: INVERTED.TODO_export/examples/ko/splash_lyx22 3/8 Test #5761: INVERTED.TODO_export/examples/ko/splash_lyx22 ..***Failed6.71 sec Start 5762: INVERTED.TODO_export/examples/ko/splash_lyx23 4/8 Test #5762: INVERTED.TODO_export/examples/ko/splash_lyx23 ..***Failed6.07 sec Start 5763: lyx2lyx/examples/ko/splash 5/8 Test #5763: lyx2lyx/examples/ko/splash . Passed0.09 sec Start 5764: check_load/examples/ko/splash 6/8 Test #5764: check_load/examples/ko/splash .. Passed0.53 sec Start 5765: export/examples/ko/splash_xhtml 7/8 Test #5765: export/examples/ko/splash_xhtml Passed0.62 sec Start 5766: DEFAULTOUTPUT_export/examples/ko/splash_pdf4_systemF 8/8 Test #5766: DEFAULTOUTPUT_export/examples/ko/splash_pdf4_systemF ... Passed4.80 sec 75% tests passed, 2 tests failed out of 8 Korneldiff --git a/lib/examples/ko/splash.lyx b/lib/examples/ko/splash.lyx index 2f0f45e..782d8c0 100644 --- a/lib/examples/ko/splash.lyx +++ b/lib/examples/ko/splash.lyx @@ -1,7 +1,7 @@ -#LyX 2.3 created this file. For more info see http://www.lyx.org/ -\lyxformat 544 +#LyX 2.4 created this file. For more info see https://www.lyx.org/ +\lyxformat 566 \begin_document \begin_header \save_transient_properties true \origin /systemlyxdir/examples/ko/ \textclass article @@ -9,27 +9,29 @@ \maintain_unincluded_children false \language korean \language_package default \inputencoding utf8 \fontencoding OT1 -\font_roman "default" "default" -\font_sans "default" "default" -\font_typewriter "default" "default" +\font_roman "default" "NanumGothic" +\font_sans "default" "NanumGothic Eco" +\font_typewriter "default" "NanumGothicCoding" \font_math "auto" "auto" \font_default_family default -\use_non_tex_fonts false +\use_non_tex_fonts true \font_sc false \font_osf false \font_sf_scale 100 100 \font_tt_scale 100 100 \use_microtype false \use_dash_ligatures false \graphics default -\default_output_format default +\default_output_format pdf4 \output_sync 0 \bibtex_command default \index_command default +\float_placement class +\float_alignment class \paperfontsize default \spacing single \use_hyperref false \papersize default \use_geometry false signature.asc Description: This is a digitally signed message part.
Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X
Am 05.01.2019 um 12:03 schrieb Enrico Forestieri : > > On Fri, Jan 04, 2019 at 11:30:08PM +0100, Stephan Witt wrote: >> Am 04.01.2019 um 18:54 schrieb Enrico Forestieri : >>> >>> On Fri, Jan 04, 2019 at 05:19:57PM +0100, Stephan Witt wrote: Am 04.01.2019 um 17:05 schrieb Enrico Forestieri : > Then why not using a wrapper that takes the specified paths, makes them > absolute by prefixing the current directory if they are relative and then > calls the inkscape shell script? Because it’s tedious and error prone to handle all possible parameters and care for spaces in path names and don’t change other parameters. >>> >>> I see. In this case, in order to keep the same meaning, "$$i" and "$$o" >>> should always produce relative paths and the code should be audited for >>> adding "$$p" where actually needed. >>> >> The argument from JMarc about possible breaking existing user preferences >> is a real strong one. I don’t have a better idea... > > Note that we have the pref2prefs.py script for converting user preferences. > It would suffice replacing "$$i" with "$$p$$i" and "$$o" with "$$p$$o" > where appropriate. So, no breaking would occur. > >> the attached patch would >> be a real pragmatic approach, IMO. Furthermore it gives the possibility to >> solve (or hide) the problem in 2.3.x branch too. > > I really don't like the different meaning that is attached to "$$p" in this > case. This is bound to bite in the future. > >> If this patch is not acceptable I think the next best move is to catch the >> relative path names in the Mac specific inkscape wrapper script. Just as you >> proposed it. I thought about it and think it’s doable because the calls from >> Converters::convert use normalized file names without spaces returned by >> DocFileName::mangledFileName. >> >> What do you think? > > The wrapper is the quickest solution, maybe, but the unification of the > meaning of "$$i" and "$$o" is the cleanest. However, if you do not have > time to tackle it, pragmatically, I would say go with the wrapper approach, > as this issue has seemingly always been there and only showed in the > particular case of the Mac. Yes, this means postponing the problem but we > often have to live with compromises. I did it with the wrapper script approach and pushed it with commit caa1dd2aee. I’ve tested it on Mac extensively. It shouldn’t change anything on other platforms. But I’d be glad to hear if you can test it on Linux too and tell me it works for you. So, we postpone the problem - but this is ok for me. Thank you for the discussion. Stephan
define LYX_USE_LONG_LONG
Hello list, I'm currently maintaining the port of Lyx for OpenBSD, we recently we moved from Lyx 2.2.3 to 2.3.2 (maybe you want to update https://www.lyx.org/Download). During the building process I found the following problem: #ifdef HAVE_LONG_LONG_INT #if SIZEOF_LONG_LONG > SIZEOF_LONG #define LYX_USE_LONG_LONG #endif #endif That is an extract from configure.ac, where you currently check if the size of long long is greater than long. Currently on OpenBSD amd64 the sizes are the same, so LYX_USE_LONG_LONG is undef. This triggers errors during compilation time, given that some C++ functions/types return a long long value. For example: std::time_t So in some cases there are problems by not expecting a long long value. The simple solution in our case was to define LYX_USE_LONG_LONG by changing "greater" to "greater or equal": #if SIZEOF_LONG_LONG >= SIZEOF_LONG I attach a git diff with the change, working in our case but this might have consequences that I'm unaware of. Works fine on OpenBSD amd64 and i386. We are OK with keeping our simple patch, but this might solve the problems of other OSes/architectures. Thanks for Lyx, I personally use it all the time and I love it. Elias M. Mariani. OpenBSD.diff Description: Binary data
Re: [LyX/master] Bibliography.lyx: add a reference so it compiles
On Sat, Jan 05, 2019 at 10:18:42AM +0100, Jürgen Spitzmüller wrote: > Am Freitag, den 04.01.2019, 14:54 -0500 schrieb Scott Kostyshak: > > > > I see. I reverted the commit and added an explanatory note at > > 91d8aea8. > > It seems strange to me to include such a lengthy user preamble if the > > .lyx file is not expected to be compiled on its own. Isn't the > > preamble > > ignored when compiled as an included document? Can I remove this > > preamble or would you prefer to keep it? > > You can remove it, if you want. I just copied another child when I > generated this one. You can probably also remove the "default master" > from the Bibliography document (this will get rid of the "two parents" > warning, and it is not of much use here anyway). > > Remember that all changes should also be done in stable. Sounds good. Done in master at 6e815d3e. Recent changes cherry-picked to 2.3.x at 5bcb0ca6. Scott signature.asc Description: PGP signature
Re: acmart.layout: ListCommand for float sidebar
On 1/5/19 1:27 PM, Jean-Marc Lasgouttes wrote: > Le 05/01/2019 à 18:08, Richard Kimberly Heck a écrit : >> Because an empty string is what triggers the warning that Scott >> originally reported: >> >> TextClass.cpp (1497): The layout does not provide a list command for the >> float >> `sidebar'. LyX will not be able to produce a float list. >> >> I.e., an empty string might just mean that the user has forgotten to >> define a list command. So what we need is something that explicitly >> says, "There's no list command". > > The ListCommand could be initialized to something like "__missing__" > by default, so that we know whether something has been given by the user. I thought about this, too, and would be happy to do it that way. Riki
Re: serious bug (fedora issue?)
Hello, Was the information that I provided useful? I also have to face other crash issues. I will try to communicate after the previous one have been solved. Thank. === Patrick DUPRÉ | | email: pdu...@gmx.com Laboratoire de Physico-Chimie de l'Atmosphère | | Université du Littoral-Côte d'Opale | | ===
Re: How to crash lyx: option #4269
On Monday, 31 December 2018 15.22.56 WET Enrico Forestieri wrote: > Never mind. I discovered that it crashes only when configuring with > --enable-stdlib-debug and verified that the patch fixes it. I noticed that you committed the fix. Thank you. :-) -- José Abílio
Re: acmart.layout: ListCommand for float sidebar
Le 05/01/2019 à 18:08, Richard Kimberly Heck a écrit : Because an empty string is what triggers the warning that Scott originally reported: TextClass.cpp (1497): The layout does not provide a list command for the float `sidebar'. LyX will not be able to produce a float list. I.e., an empty string might just mean that the user has forgotten to define a list command. So what we need is something that explicitly says, "There's no list command". The ListCommand could be initialized to something like "__missing__" by default, so that we know whether something has been given by the user. OTOH, this warning is just a helper here, and we don't have a lot of those. A solution would be to remove it :) Anyway, we should not change the reasonable syntax just because we have a nice warning in place. JMarc
Re: [RFC] Try to compute row height like it should be done
On Sat, Jan 05, 2019 at 05:38:30PM +0100, Jürgen Spitzmüller wrote: > Am Samstag, den 05.01.2019, 11:47 +0100 schrieb Enrico Forestieri: > > Yes, I would ignore the leading > > Why? For what I understand, the leading is a suggested spacing to add to account for accents and similar that might otherwise overlap. However, if we already provide for a larger line spacing (because we have inserts to take into account), we shouldn't need this correction and even avoid changing the spacing if two different fonts with different leading suggestions are used on the same line. -- Enrico
Re: acmart.layout: ListCommand for float sidebar
On 1/5/19 6:22 AM, Jean-Marc Lasgouttes wrote: > Le 5 janvier 2019 04:25:19 GMT+01:00, Richard Kimberly Heck > a écrit : I don't think there is one. Perhaps we should add a "NONE" option, >> or something, and check for that. The attached might work. >>> Tested and works well. >> I guess the question is just whether others think this is the right >> approach. Unfortunately, we cannot use an empty string here >> >> Riki > Why can't we use an empty string? Because an empty string is what triggers the warning that Scott originally reported: TextClass.cpp (1497): The layout does not provide a list command for the float `sidebar'. LyX will not be able to produce a float list. I.e., an empty string might just mean that the user has forgotten to define a list command. So what we need is something that explicitly says, "There's no list command". Riki
Re: [RFC] Try to compute row height like it should be done
Am Samstag, den 05.01.2019, 11:47 +0100 schrieb Enrico Forestieri: > Yes, I would ignore the leading Why? Jürgen signature.asc Description: This is a digitally signed message part
Re: acmart.layout: ListCommand for float sidebar
Le 5 janvier 2019 04:25:19 GMT+01:00, Richard Kimberly Heck a écrit : > >>> I don't think there is one. Perhaps we should add a "NONE" option, >or >>> something, and check for that. The attached might work. >> Tested and works well. > >I guess the question is just whether others think this is the right >approach. Unfortunately, we cannot use an empty string here > >Riki Why can't we use an empty string? JMarc
Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X
On Fri, Jan 04, 2019 at 11:30:08PM +0100, Stephan Witt wrote: > Am 04.01.2019 um 18:54 schrieb Enrico Forestieri : > > > > On Fri, Jan 04, 2019 at 05:19:57PM +0100, Stephan Witt wrote: > >> Am 04.01.2019 um 17:05 schrieb Enrico Forestieri : > >>> Then why not using a wrapper that takes the specified paths, makes them > >>> absolute by prefixing the current directory if they are relative and then > >>> calls the inkscape shell script? > >> > >> Because it’s tedious and error prone to handle all possible parameters and > >> care for spaces in path names and don’t change other parameters. > > > > I see. In this case, in order to keep the same meaning, "$$i" and "$$o" > > should always produce relative paths and the code should be audited for > > adding "$$p" where actually needed. > > > The argument from JMarc about possible breaking existing user preferences > is a real strong one. I don’t have a better idea... Note that we have the pref2prefs.py script for converting user preferences. It would suffice replacing "$$i" with "$$p$$i" and "$$o" with "$$p$$o" where appropriate. So, no breaking would occur. > the attached patch would > be a real pragmatic approach, IMO. Furthermore it gives the possibility to > solve (or hide) the problem in 2.3.x branch too. I really don't like the different meaning that is attached to "$$p" in this case. This is bound to bite in the future. > If this patch is not acceptable I think the next best move is to catch the > relative path names in the Mac specific inkscape wrapper script. Just as you > proposed it. I thought about it and think it’s doable because the calls from > Converters::convert use normalized file names without spaces returned by > DocFileName::mangledFileName. > > What do you think? The wrapper is the quickest solution, maybe, but the unification of the meaning of "$$i" and "$$o" is the cleanest. However, if you do not have time to tackle it, pragmatically, I would say go with the wrapper approach, as this issue has seemingly always been there and only showed in the particular case of the Mac. Yes, this means postponing the problem but we often have to live with compromises. -- Enrico
Re: [RFC] Try to compute row height like it should be done
On Fri, Jan 04, 2019 at 10:40:34PM +0100, Jean-Marc Lasgouttes wrote: > Le 04/01/2019 à 19:23, Enrico Forestieri a écrit : > > Please, don't make too close the text lines. A larger spacing allows to > > accomodate insets without the need of adjusting the height between lines, > > avoiding a nonuniform spacing that looks bad. > > Don't worry, I will make it larger. My question right now is to understand > what the font designers want me to do and why they provide la leading() > value. Possibilities could be: > * ignore leading of font and add 15 or 02% of total height Yes, I would ignore the leading and even add 25% of total height. See the case h×1.25 here: https://en.wikipedia.org/wiki/Leading#Practices > * add leading and then 15 or 02% of total height > * use 15 or 20% of total height as leading when it is 0. -- Enrico
Re: [LyX/master] Bibliography.lyx: add a reference so it compiles
Am Freitag, den 04.01.2019, 14:54 -0500 schrieb Scott Kostyshak: > > I see. I reverted the commit and added an explanatory note at > 91d8aea8. > It seems strange to me to include such a lengthy user preamble if the > .lyx file is not expected to be compiled on its own. Isn't the > preamble > ignored when compiled as an included document? Can I remove this > preamble or would you prefer to keep it? You can remove it, if you want. I just copied another child when I generated this one. You can probably also remove the "default master" from the Bibliography document (this will get rid of the "two parents" warning, and it is not of much use here anyway). Remember that all changes should also be done in stable. Thanks Jürgen > > Scott signature.asc Description: This is a digitally signed message part
