Re: Alpha 2? Beta 1?

[Jürgen Spitzmüller]

Am Montag, dem 25.01.2021 um 19:52 + schrieb José Abílio Matos:
> On Monday, January 25, 2021 7:26:34 PM WET Pavel Sanda wrote:
> > But I don't think it matters much in the end,
> > Pavel
> 
> I agree with Pavel here. :-)

Me, too. I would add that we shouldn't wait too long for new features.
So if the ePub support is not there within a to-be-specified time,
postpone it to a later release.

OTOH I think a second alpha is fair if it is done soon.

For beta, I would suggest to freeze features.

Jürgen

> 
> -- 
> José Abílio



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: ctests for Additioonal.lyx lyx2lyx round trip failing on master

[Jürgen Spitzmüller]

Am Montag, dem 25.01.2021 um 15:09 -0500 schrieb Scott Kostyshak:
> It seems they fail the convergence criteria of the test. That is,
> with successive round trips the .lyx files keep changing. This is
> expected in some cases (and we can adapt the tests), but I don't know
> enough to know whether it's expected here. 

It's expected. We insert ERT in reversion which we do not remove in
conversion (we generally don't do this).

> Also, it was surprising that the English version conver es but not
> the Spanish version. Here [1] is a screenshot of the Spanish
> Additional manual after a few iterations.
> Interestingly, the first column has only one pair of ERTs, but the
> second and third columns show the failed convergence. Here [2] is a
> screenshot of the English Additional manual in case it is helpful for
> comparison.

Yes, the ERTs are only inserted if the multirows have multiple
paragraphs or newline insets.

This is all expected. You can't expect a LyX document of this
complexity survive multiple cycles.

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: Insert menu

[Jürgen Spitzmüller]

Am Dienstag, dem 26.01.2021 um 10:16 +1300 schrieb Andrew Parsloe:
> English *syntax* perhaps? 

No, semantics (semasiology of "list" vs. "Verzeichnis").

> The semantics I had in mind was the division of a book into three
> parts: prelims (i.e. preliminary pages), text or body of the book,
> and end matter. Prelims is where the TOC and lists of tables,
> figures, ... go. According to the style book that was my bible during
> my former life as an indexer, Appendix, Notes, Glossary, Bibliography
> and Index constitute  end matter. In fact, seeing Appendix here has
> prompted me to transfer "Start Appendix Here" from the Document menu
> to the "End matter" submenu in my personalized stdmenus.inc.

I prefer functional category over positional. TOC, LOF, LOT (the latter
two often in the backmatter BTW, sometimes even the former), indexes,
nomenclature, references and glossaries all are lists with entries that
refer to specific parts of the document. This is their common function.

The position differs historically and culturally (probably also between
genres).

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: Insert menu

[Andrew Parsloe]

On 25/01/2021 11:15 pm, Jürgen Spitzmüller wrote:

Am Montag, dem 25.01.2021 um 16:56 +1300 schrieb Andrew Parsloe:

(LyX 2.4.0 alpha) Inserted a TOC recently. My eye ran down the Insert
menu to Table..., realised that wasn't it, then back up the list to
"List/Contents/References", found and duly inserted the TOC inset.

Yes. This has been renamed, as the old name "List/TOC" was not adequate
(it didn't cover "References", and TOC is too cryptic).


Looking at the items in the submenu, I feel Tthree of them (index,
nomenclature and bibliography) could helpfully be reassigned to a
separate item in the Insert menu, tentatively called "End matter".
Although the items in "End matter" are not always placed there, I
think that is generally the case, whereas lists of tables and figures
etc. are usually placed at the front.

I don't think this is a very good category name. Also I think that
these are all sorts of "lists" that can be grouped together. In German,
we have the general term "Verzeichnisse" which perfectly fits them all
(TOC is "Inhaltsverzeichnis", Bibliography "Literaturverzeichnis", List
of Figure "Abbildungsverzeichnis", Index "Stichwortverzeichnis"). It is
too bad that English (apparently due to some historical contingencies)
distinguishes "lists", "tables" etc. So we need this rather crude entry
for English.

However, I do not think that we should structure the menu based on
English semantics.

Jürgen


English *syntax* perhaps? The semantics I had in mind was the division 
of a book into three parts: prelims (i.e. preliminary pages), text or 
body of the book, and end matter. Prelims is where the TOC and lists of 
tables, figures, ... go. According to the style book that was my bible 
during my former life as an indexer, Appendix, Notes, Glossary, 
Bibliography and Index constitute  end matter. In fact, seeing Appendix 
here has prompted me to transfer "Start Appendix Here" from the Document 
menu to the "End matter" submenu in my personalized stdmenus.inc.


Andrew

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: ctests for Additioonal.lyx lyx2lyx round trip failing on master

[Scott Kostyshak]

On Mon, Jan 25, 2021 at 11:35:50AM -0500, Scott Kostyshak wrote:
> On Mon, Jan 25, 2021 at 12:05:32PM +0100, Jürgen Spitzmüller wrote:
> > Am Sonntag, dem 24.01.2021 um 14:23 -0500 schrieb Scott Kostyshak:
> > > To reproduce, export Additional.lyx to 2.3.x format. Then open that
> > > exported file in master and compile.
> > > 
> > > There are two issues (perhaps in the end the same?):
> > > 
> > > 1. Terminal output gives the following:
> > > 
> > >   Paragraph ended in line 26020
> > >   Missing \end_layout.
> > > 
> > > 2. There is a LaTeX error:
> > > 
> > > ! Missing } inserted.
> > >  
> > >     }
> > > l.5938 ...e up/down/\\left/right\end{cellvarwidth}
> > >   }
> > > 
> > > I believe we don't require compilation to succeed, so if fixing (2)
> > > is
> > > too complicated, let me know and I'll adapt the tests.
> > 
> > Should be fixed.
> 
> Thanks for the quick fix.

The "doc/Additional" ctests all pass now, but the following ctests for
the Spanish Additional manual fail:

  2179 - export/doc/es/Additional_lyx16 (Failed)
  2180 - export/doc/es/Additional_lyx20 (Failed)
  2181 - export/doc/es/Additional_lyx21 (Failed)
  2182 - export/doc/es/Additional_lyx22 (Failed)
  2183 - export/doc/es/Additional_lyx23 (Failed)

It seems they fail the convergence criteria of the test. That is, with
successive round trips the .lyx files keep changing. This is expected in
some cases (and we can adapt the tests), but I don't know enough to know
whether it's expected here. Also, it was surprising that the English
version converges but not the Spanish version. Here [1] is a screenshot
of the Spanish Additional manual after a few iterations. Interestingly,
the first column has only one pair of ERTs, but the second and third
columns show the failed convergence. Here [2] is a screenshot of the
English Additional manual in case it is helpful for comparison.

Let me know if I should adapt the tests (i.e., if the failed convergence
is unavoidable or if it is avoidable but just not worth the time or
complexity to fix).

Scott


[1] https://www.dropbox.com/s/evovbrghbrzoij6/es.png?dl=0
[2] https://www.dropbox.com/s/2zrviwbqzsiqwlx/en.png?dl=0


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Alpha 2? Beta 1?

[José Abílio Matos]

On Monday, January 25, 2021 7:26:34 PM WET Pavel Sanda wrote:
> But I don't think it matters much in the end,
> Pavel

I agree with Pavel here. :-)

-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Alpha 2? Beta 1?

[Pavel Sanda]

On Mon, Jan 25, 2021 at 07:59:02PM +0100, Thibaut Cuvelier wrote:
> > A couple fairly significant regressions have now been fixed in Alpha 1,
> > so it looks like time to do another release. The default would be to go
> > with Alpha 2. But, besides some missing layout files (my fault) and a
> > problem opening files, we have not had any serious bug reports from
> > Alpha 1 (that aren't already in 2.3.x). Should we think about a beta
> > release? To be honest, I don't know myself what people think the
> > difference is between the two, so I'd welcome suggestions.
> >
> 
> I would really like to ship an ePub export in 2.4, building upon the
> DocBook export. I think I could work on that this week.

This would be great.
 
> For alpha vs. beta, I often see that alpha is near-release, but not yet
> feature-frozen, while the developers would like feedback on the current
> state of the software; beta is feature-frozen, with only bug fixes included
> in one release to the other (RC meaning that only critical bug fixes are
> being fixed).

Per our own definitions alpha means only *few* new features are expected to
happen for 2.4, beta means only *small* changes intended for 2.4.

If you wait for ePub to finish then I think it's time for beta, if you
want to push release now, then I'd still go with alpha.

But I don't think it matters much in the end, 
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Alpha 2? Beta 1?

[Thibaut Cuvelier]

On Mon, 25 Jan 2021 at 19:31, Richard Kimberly Heck 
wrote:

> Hi, all,
>
> A couple fairly significant regressions have now been fixed in Alpha 1,
> so it looks like time to do another release. The default would be to go
> with Alpha 2. But, besides some missing layout files (my fault) and a
> problem opening files, we have not had any serious bug reports from
> Alpha 1 (that aren't already in 2.3.x). Should we think about a beta
> release? To be honest, I don't know myself what people think the
> difference is between the two, so I'd welcome suggestions.
>

I would really like to ship an ePub export in 2.4, building upon the
DocBook export. I think I could work on that this week.

For alpha vs. beta, I often see that alpha is near-release, but not yet
feature-frozen, while the developers would like feedback on the current
state of the software; beta is feature-frozen, with only bug fixes included
in one release to the other (RC meaning that only critical bug fixes are
being fixed).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Alpha 2? Beta 1?

[Richard Kimberly Heck]

Hi, all,

A couple fairly significant regressions have now been fixed in Alpha 1,
so it looks like time to do another release. The default would be to go
with Alpha 2. But, besides some missing layout files (my fault) and a
problem opening files, we have not had any serious bug reports from
Alpha 1 (that aren't already in 2.3.x). Should we think about a beta
release? To be honest, I don't know myself what people think the
difference is between the two, so I'd welcome suggestions.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: ctests for Additioonal.lyx lyx2lyx round trip failing on master

[Scott Kostyshak]

On Mon, Jan 25, 2021 at 12:05:32PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 24.01.2021 um 14:23 -0500 schrieb Scott Kostyshak:
> > To reproduce, export Additional.lyx to 2.3.x format. Then open that
> > exported file in master and compile.
> > 
> > There are two issues (perhaps in the end the same?):
> > 
> > 1. Terminal output gives the following:
> > 
> >   Paragraph ended in line 26020
> >   Missing \end_layout.
> > 
> > 2. There is a LaTeX error:
> > 
> > ! Missing } inserted.
> >  
> >     }
> > l.5938 ...e up/down/\\left/right\end{cellvarwidth}
> >   }
> > 
> > I believe we don't require compilation to succeed, so if fixing (2)
> > is
> > too complicated, let me know and I'll adapt the tests.
> 
> Should be fixed.

Thanks for the quick fix.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Prevent branch background color from leaking out of the document

[Jürgen Spitzmüller]

Am Montag, dem 25.01.2021 um 13:45 +0100 schrieb Jean-Marc Lasgouttes:
> What I propose (not 2.4 business IMO) is
> 
> * when e.g. the BranchList object requires a color, it can just give
> a 
> rgb triplet and require a color code. The name is just an
> intermediate 
> valuethat is of no use. If the code requests ColorCode ids when
> needed, 
> there is no issue of per-document colors. The downside is that a 
> long-running LyX session could have a complexity issue (?).
> 
> * similarly in Buffer params, the code can request a ColorCode for
> each 
> customizable color and set it to the RGB value read from the LyX
> file.
> 
> * Maybe get rid of Color class: it can be nicely represented by an
> int, like
>    base_color + (1 << 16) * merge_color
> If not doing that, then we could use always a Color object in places 
> where a ColorCode is currently used.
> 
> Better now?

This is all fine as long as we can use semantic colors in the document
as much as we can. I.e., only write static colors to the document if
absolutely necessary.

For branch, I'd like to enhance the color interface in a way that
encourages people to assign a semantic color rather than setting a
static color value (due to themeability). Same for customizable text
colors (due to proper semantic markup).

So if these rgb triplet is just used internally in these cases, I am
fine with it. If BufferParams need to read and write them, I am
opposed.

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

FindAdv, request for comments

[Kornel Benko]

Problems with FindAdv and search with not ignored format

What we have now is something 'neither fish nor fowl'.

For instance for the search of characters with a specific size
we use strings/regexes wrapped with the size-spec. All is nice, until the size 
is the
default in the document. In that case the wrapping has no effect (because the 
text
created by latex output does not contain this info)

Same is valid for language, color, family, series, shape, etc.
Also we don't have the options to exclude characters with specific features 
from search.
(like search for words which are not part of a Latin sequence)

I am not sure, if investing more into this (without creating a nex export-type 
for search
(ala Docbook)) would get better sollutions.

Comment are appreciated.

Kornel


pgpp_dluhgrg3.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Prevent branch background color from leaking out of the document

[Jean-Marc Lasgouttes]

Le 22/01/2021 à 11:12, Jürgen Spitzmüller a écrit :

My take is that the name is only needed for the colors of GUI
elements
that can be set in the color preferences.


What about the colors set in document settings (branch background,
greyedouttext, box background, index labels)?


So, I have been doing some reading of the code, which obviously help 
discussion.


There are 3 notions of colors:

* ColorCode is an enum, used in FontInfo. This is nice in particular for 
the GUI, but not for using colors in documents, where we are limited to 
an arbitrary list of colors. A ColorCode can be bound to any RGB color.


* Color is is a weird class that replaces somehow transparency, by 
specifying a merge color and a base color and then computing a mix of 
them (not sure whether doing the fusion in RGB space is the right thing 
to do, but it is what it is). Actually, FontInfo uses a ColorCode enum 
_and_ a Color object :-/


* RGBColor is used for elements that should have a color particular to 
the document. It is defined by (r,g,b) components, but to be used, it is 
necessary to give them a name, and then to ask ColorSet to allocate a 
ColorCode to them. Indeed, the only interface that the frontend 
understands is the ColorCode (or Color pair).



What I propose (not 2.4 business IMO) is

* when e.g. the BranchList object requires a color, it can just give a 
rgb triplet and require a color code. The name is just an intermediate 
valuethat is of no use. If the code requests ColorCode ids when needed, 
there is no issue of per-document colors. The downside is that a 
long-running LyX session could have a complexity issue (?).


* similarly in Buffer params, the code can request a ColorCode for each 
customizable color and set it to the RGB value read from the LyX file.


* Maybe get rid of Color class: it can be nicely represented by an int, like
  base_color + (1 << 16) * merge_color
If not doing that, then we could use always a Color object in places 
where a ColorCode is currently used.


Better now?
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Page Break vs New Page

[Jürgen Spitzmüller]

Am Sonntag, dem 24.01.2021 um 13:50 -0500 schrieb Richard Kimberly
Heck:
> Both our user guide, section 3.5.5, and this page:
> 
> https://latexref.xyz/_005cnewpage.html
> 
> say that \pagebreak stretches the page, though it does not always
> seem
> to do so.

See also
https://tex.stackexchange.com/a/9855/19291

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: Page Break vs New Page

[Jean-Marc Lasgouttes]

Le 25/01/2021 à 11:48, Jean-Pierre Chrétien a écrit :
I'm sure I found it when I looked for a translation of the terms  
newpage, pagebreak, etc.
I guess thet English-speaking people have understood that translators in 
other languages had to find something explicit to translate these words.

Shouldn't we continue this discussion on lyx-fr ?


Sure. I guess finding out why these two types of page breaking are 
supported in LaTeX may help, though.


JMarc

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: ctests for Additioonal.lyx lyx2lyx round trip failing on master

[Jürgen Spitzmüller]

Am Sonntag, dem 24.01.2021 um 14:23 -0500 schrieb Scott Kostyshak:
> To reproduce, export Additional.lyx to 2.3.x format. Then open that
> exported file in master and compile.
> 
> There are two issues (perhaps in the end the same?):
> 
> 1. Terminal output gives the following:
> 
>   Paragraph ended in line 26020
>   Missing \end_layout.
> 
> 2. There is a LaTeX error:
> 
> ! Missing } inserted.
>  
>     }
> l.5938 ...e up/down/\\left/right\end{cellvarwidth}
>   }
> 
> I believe we don't require compilation to succeed, so if fixing (2)
> is
> too complicated, let me know and I'll adapt the tests.

Should be fixed.

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: Page Break vs New Page

[Jean-Pierre Chrétien]

Le 25/01/2021 à 10:59, Jean-Marc Lasgouttes a écrit :

Le 25/01/2021 à 10:43, Jean-Pierre Chrétien a écrit :

Le 25/01/2021 à 10:29, Jean-Marc Lasgouttes a écrit :
« fer à gauche » means that the characters are stacked from the left limit, 
i.e left alignment

« fer en haut » means that the characters are stacked from the upper limit

https://fr.wikipedia.org/wiki/Justification_(typographie)

Obviously, the page does not exist in English.


Why not? Don't they do typography too?


Sure, under a different name:

 https://en.wikipedia.org/wiki/Typographic_alignment

But this one does not say a word about vertical justification either.





What about
« aligné à gauche » instead of « fer à gauche »
« calé en haut de page » instead of « fer en haut »


I do not see the reference to "en haut" in te*he wikipedia page. This is the 
part I do not really get.


I'm sure I found it when I looked for a translation of the terms  newpage, 
pagebreak, etc.
I guess thet English-speaking people have understood that translators in other 
languages had to find something explicit to translate these words.

Shouldn't we continue this discussion on lyx-fr ?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Insert menu

[Jürgen Spitzmüller]

Am Montag, dem 25.01.2021 um 16:56 +1300 schrieb Andrew Parsloe:
> (LyX 2.4.0 alpha) Inserted a TOC recently. My eye ran down the Insert
> menu to Table..., realised that wasn't it, then back up the list to 
> "List/Contents/References", found and duly inserted the TOC inset.

Yes. This has been renamed, as the old name "List/TOC" was not adequate
(it didn't cover "References", and TOC is too cryptic).

> Looking at the items in the submenu, I feel three of them (index, 
> nomenclature and bibliography) could helpfully be reassigned to a 
> separate item in the Insert menu, tentatively called "End matter". 
> Although the items in "End matter" are not always placed there, I
> think that is generally the case, whereas lists of tables and figures
> etc. are usually placed at the front. 

I don't think this is a very good category name. Also I think that
these are all sorts of "lists" that can be grouped together. In German,
we have the general term "Verzeichnisse" which perfectly fits them all
(TOC is "Inhaltsverzeichnis", Bibliography "Literaturverzeichnis", List
of Figure "Abbildungsverzeichnis", Index "Stichwortverzeichnis"). It is
too bad that English (apparently due to some historical contingencies)
distinguishes "lists", "tables" etc. So we need this rather crude entry
for English.

However, I do not think that we should structure the menu based on
English semantics.

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: Page Break vs New Page

[Jean-Marc Lasgouttes]

Le 25/01/2021 à 10:43, Jean-Pierre Chrétien a écrit :

Le 25/01/2021 à 10:29, Jean-Marc Lasgouttes a écrit :
« fer à gauche » means that the characters are stacked from the left 
limit, i.e left alignment

« fer en haut » means that the characters are stacked from the upper limit

https://fr.wikipedia.org/wiki/Justification_(typographie)

Obviously, the page does not exist in English.


Why not? Don't they do typography too?



What about
« aligné à gauche » instead of « fer à gauche »
« calé en haut de page » instead of « fer en haut »


I do not see the reference to "en haut" in te*he wikipedia page. This is 
the part I do not really get.


JMarc

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Page Break vs New Page

[Jean-Pierre Chrétien]

Le 25/01/2021 à 10:29, Jean-Marc Lasgouttes a écrit :



But the problem with "adequate French typographical expressions" is that I can 
never figure out what "fer en haut" might mean.


A bit confusing I admit and difficult to explain in English. « fer » is the 
limit of the frame inside which typographers used to stack characters. So


« fer à gauche » means that the characters are stacked from the left limit, i.e 
left alignment

« fer en haut » means that the characters are stacked from the upper limit

https://fr.wikipedia.org/wiki/Justification_(typographie)

Obviously, the page does not exist in English.

What about
« aligné à gauche » instead of « fer à gauche »
« calé en haut de page » instead of « fer en haut »

--
Jean-Pierre



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Page Break vs New Page

[Jean-Marc Lasgouttes]

Le 25/01/2021 à 09:58, Jean-Pierre Chrétien a écrit :

Le 24/01/2021 à 18:36, Richard Kimberly Heck a écrit :

Over on lyx-users, we got a question that uncovered the fact that these
names are not very descriptive. (The user had used Page Break and gotten
surprising results: a very stretched Table of Contents.) The line breaks
have more descriptive names. Is there something else we could use for
Page Break that would indicate what it does? Something like "Page Break
(Stretch Page)" would work, but is kind of long


Right, I have had for a long time translations which use adequate French 
typographical expressions


Page Break    as Saut de page (fer en haut)
New Page  as Saut de page (justifié)
Clear Page    as Saut de page (vide le tampon)
Clear Double Page as Saut de page impaire


But the problem with "adequate French typographical expressions" is that 
I can never figure out what "fer en haut" might mean.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Page Break vs New Page

[Jean-Pierre Chrétien]

Le 25/01/2021 à 09:58, Jean-Pierre Chrétien a écrit :
.


Right, I have had for a long time translations which use adequate French 
typographical expressions


Page Break    as Saut de page (fer en haut)
New Page  as Saut de page (justifié)
Clear Page    as Saut de page (vide le tampon)
Clear Double Page as Saut de page impaire



That was for 2.3, I see that I will need to add

No Page Break   as Saut de page interdit

in 2.4.0

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [CONFIRMED] Delimiter issue in 2.3.6.1 and in master

[Dr Eberhard Lisse]

I do not see it on MacOS 11.1 with 2.3.6.2 either.

el


On 22/01/2021 18:22, Joel Kulesza wrote:
> On Fri, Jan 22, 2021 at 3:33 AM José Abílio Matos  > wrote:
> 
> On Thursday, January 21, 2021 9:44:09 PM WET Richard Kimberly Heck wrote:
> 
> > Yes, I see it, and in master too. Screenshot attached.
> 
> >
> 
> > Riki
> 
> 
> Hi Riki,
> 
>   I do not see this on Fedora 33 using both 2.3.6.1 and alpha1 packages.
> 
> 
> I am just adding another data point to this report.
> 
> -- 
> 
> José Abílio
> 
> 
> Another data point: I do not see this on macOS 11.0.1 with 2.4.0a1.
> 
> Thanks,
> Joel 
> 


-- 
To email me replace 'nospam' with 'el'

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Page Break vs New Page

[Jean-Pierre Chrétien]

Le 24/01/2021 à 18:36, Richard Kimberly Heck a écrit :

Over on lyx-users, we got a question that uncovered the fact that these
names are not very descriptive. (The user had used Page Break and gotten
surprising results: a very stretched Table of Contents.) The line breaks
have more descriptive names. Is there something else we could use for
Page Break that would indicate what it does? Something like "Page Break
(Stretch Page)" would work, but is kind of long


Right, I have had for a long time translations which use adequate French 
typographical expressions


Page Breakas Saut de page (fer en haut)
New Page  as Saut de page (justifié)
Clear Pageas Saut de page (vide le tampon)
Clear Double Page as Saut de page impaire

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel