On Tuesday, July 12, 2016 6:20:38 AM WEST Richard Heck wrote: > commit e57889ff2f38ed8e804a7e3c7e62114e31bf7715 > Author: Richard Heck <rgh...@lyx.org> > Date: Tue Jul 12 00:20:27 2016 -0400 > > Document new inverted branch insets in User Guide. Also add note to > RELEASE_NOTES.
Since we are at the begin of the development cycle I would like to propose the addition of new tests for the lyx upgrade format with the purpose of having the lyx2lyx format equal to the format the lyx reads and writes. My main motivation comes from this bug: lyx2lyx roundtrip fails with templates/IEEEtran-Journal.lyx http://www.lyx.org/trac/ticket/9909 Honestly I am not sure if we should spend more time with bug and if we should get the lessons from it to improve the convertion to future formats. In short the problem occurs applying iteratively a convertion to file written by lyx on older version. In the case of this bug we have: lyx -e lyx16 IEEEtran-Journal.lyx LyX loads the original file and uses lyx2lyx to converted it to 1.6 format. Then it becomes the funny part: lyx -e lyx16 IEEEtran-Journal.16.lyx there are 3 steps here: 1) lyx loads the IEEEtran-Journal.16.lyx file and notices that it is in an older and (politely) requests lyx2lyx to convert to the only format it understands; 2) lyx loads the file converted by lyx2lyx and creates a temporary file, let us call it for convenience IEEEtran-Journal.22.lyx ; 3) lyx asks again politely to lyx2lyx to convert the IEEEtran-Journal.22.lyx file to IEEEtran-Journal.16.16.lyx; So effectively we are testing a roundtrip conversion here with 3 steps. One possible solution here would be for lyx to recognise lyx?? as a special format and to pass it the original file. In this case lyx2lyx understands that the initial and the final formats are the same and it says that there is nothing to be done. This option is correct but it does not fix the underlying problem with the file format convertion. So given this motivation the method that I propose is the following: In order to simplify the explanation let us take this file format as an example (upgrade to file format 511). In order to improve the test stage we need to keep a version of the UserGuide of the last stable version around, in this case, UserGuide-22.lyx. The test consists then on three steps: 1) lyx2lyx -o UserGuide-23.lyx UserGuide-22.lyx 2) loads the resulting file UserGuide-23.lyx and forces write with lyx, something like (I did not test the result): src/lyx -x 'command-sequence buffer-write-as UserGuide.lyx; lyx-quit' \ UserGuide-23.lyx 3) compare the diff of UserGuide-23.lyx and UserGuide.lyx to insure that it is empty. As an example I noticed that either in my tests or in this patch we get: diff --git a/lib/doc/UserGuide.lyx b/lib/doc/UserGuide.lyx index 23b126b..7bb603f 100644 --- a/lib/doc/UserGuide.lyx +++ b/lib/doc/UserGuide.lyx @@ -1,5 +1,5 @@ -#LyX 2.2 created this file. For more info see http://www.lyx.org/ -\lyxformat 508 +#LyX 2.3 created this file. For more info see http://www.lyx.org/ +\lyxformat 511 \begin_document \begin_header \save_transient_properties true @@ -68,6 +68,7 @@ enumitem \font_osf false \font_sf_scale 100 100 \font_tt_scale 100 100 +\use_microtype false \graphics default \default_output_format pdf2 \output_sync 0 @@ -134,11 +135,12 @@ enumitem \papercolumns 1 \papersides 2 \paperpagestyle default -\tracking_changes false +\tracking_changes true \output_changes false \html_math_output 0 \html_css_as_file 0 \html_be_strict true +\author 424524441 "rgheck" \end_header ... This is OK. ... @@ -8310,14 +8312,12 @@ Verbatim \end_layout \begin_layout Verbatim - This is Verbatim. \end_layout \begin_layout Verbatim \noindent \align block - The following 2 lines are empty: \end_layout ... This is not OK. Why is lyx deleting an empty line? It should not, or then lyx2lyx should not add it. If we read the development/FORMATS file there is none there that relates to this change. Note that although I am using the convertion 510->511 as an example this problem occured before so it was no introduced with this patch. Note also that in this case the change is harmless since in most cases neither lyx or lyx2lyx care about empty lines near the begin_layout. The point is that we can only or less guarantee a good reversion process if the forward upgrade is perfect. What do you think? Regards, -- José Abílio
