Re: Notes inherit surrounding font
On 2019-09-04 19:42, Richard Kimberly Heck wrote: On 9/4/19 10:30 AM, Jean-Marc Lasgouttes wrote: Le 24/08/2019 à 07:49, Daniel a écrit : Currently, IMO, notes behave in an unfortunate way in that they inherit the surrounding font. Consider the attached document which has the following structure: *Section* Text The first line is formatted as a section heading and the second as standard text. In Lyx, select all text in the document and insert a note. The actual result is that all the text looks as if it where formatted as section. This is misleading. It is also in many cases annoying. For example, when adding a longer note to a section heading it becomes huge. This is not misleading. I don't know if it's misleading, but I find it slightly annoying that the font of the note is so huge. I might want a note in a non-empty section heading to remind me of something, but I don't need it to be the same size as the heading itself. There's no real need for it to be, either. Riki I could not agree more. Daniel
Re: Notes inherit surrounding font
On 2019-09-04 16:30, Jean-Marc Lasgouttes wrote:
Le 24/08/2019 à 07:49, Daniel a écrit :
Currently, IMO, notes behave in an unfortunate way in that they
inherit the surrounding font.
Consider the attached document which has the following structure:
*Section*
Text
The first line is formatted as a section heading and the second as
standard text.
In Lyx, select all text in the document and insert a note.
The actual result is that all the text looks as if it where formatted
as section. This is misleading. It is also in many cases annoying. For
example, when adding a longer note to a section heading it becomes huge.
This is not misleading. This indicates that your note is actuall
embedded in a paragraph with style Section, so that the empty paragraph
will be output as
\section{]
This is the behavior that we shall fix.
I propose in the following patch to reset the outer layout to Plain if
it only contains the newly insert inset.
I'd appreciate if somebody could try t out to see whether I missed
something obvious. This behavior has been annoying me for ages and I am
sure we have several bug reports about that.
JMarc
Can't test currently and I am not sure I understand correctly what the
patch does. But as far as I do, I don't think I like it. If I understood
you correctly, I can replicate the behaviour of the patch in stable LyX
by inserting the inset and setting the sourrounding paragraph to
Standard. But this is not intended in some cases. For example, in order
to keep description labels together, I use a label inset that does
nothing but sourround the containing content with brackets {}. So, set a
paragraph to Description, enter the label text, mark it and insert the
label inset. But with your patch this will reset the description to
plain, right?
Daniel
Re: languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
On Wed, Sep 04, 2019 at 08:37:57PM -, Guenter Milde wrote: > On 2019-09-04, Scott Kostyshak wrote: > > On Wed, Sep 04, 2019 at 03:04:35PM +0200, Kornel Benko wrote: > >> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde: > > >> > Please try the updated "supported-languages" tests. > > Here, I get > > The following tests FAILED: > 366 - > UNRELIABLE.NONSTANDARD_export/export/latex/languages/supported-languages_polyglossia_dvi3_systemF > (Failed) > 368 - > UNRELIABLE.NONSTANDARD_export/export/latex/languages/supported-languages_polyglossia_pdf5_systemF > (Failed) > > because the TL17 version of gloss-korean.ldf contains a bug (see > unreliableTests). > > All other "supported-languages" tests pass. > > > > Strangely, the test fails for me, but when I compile manually it passes. > > The developer guide has info on which environment variable must be set to > get a LaTeX log in the test log. Hopefully this will help to find out what's > going wrong. Ah, my mistake. I did not realize that supported-languages_polyglossia-XeTeX.lyx is a new file. When I was testing manually, I was testing with supported-languages_polyglossia.lyx. Now I can reproduce the error manually. It is the same as before: "there is no . in font Noto Serif Lao Regular". To be clear, I am talking about the following test: DEFAULTOUTPUT_export/export/latex/languages/supported-languages_polyglossia-XeTeX_pdf4_systemF Scott signature.asc Description: PGP signature
Re: languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
On 2019-09-04, Scott Kostyshak wrote: > On Wed, Sep 04, 2019 at 03:04:35PM +0200, Kornel Benko wrote: >> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde: >> > Please try the updated "supported-languages" tests. Here, I get The following tests FAILED: 366 - UNRELIABLE.NONSTANDARD_export/export/latex/languages/supported-languages_polyglossia_dvi3_systemF (Failed) 368 - UNRELIABLE.NONSTANDARD_export/export/latex/languages/supported-languages_polyglossia_pdf5_systemF (Failed) because the TL17 version of gloss-korean.ldf contains a bug (see unreliableTests). All other "supported-languages" tests pass. > Strangely, the test fails for me, but when I compile manually it passes. The developer guide has info on which environment variable must be set to get a LaTeX log in the test log. Hopefully this will help to find out what's going wrong. Günter
Re: languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
On 2019-09-04, Scott Kostyshak wrote: > On Wed, Sep 04, 2019 at 12:02:02PM -, Guenter Milde wrote: >> On 2019-09-04, Scott Kostyshak wrote: >> > On Tue, Sep 03, 2019 at 09:23:54PM -, Guenter Milde wrote: >> >> On 2019-09-03, Scott Kostyshak wrote: >> >> > On Mon, Sep 02, 2019 at 10:01:13PM -0400, Scott Kostyshak wrote: >> ... >> >> >> > > I still have a "Missing character" error as follows: >> >> >> > >> >> >> > > There is no . in font Noto Serif Lao >> >> >> > > Regular/OT:script=lao;l >> >> >> > >> >> >> > > I'm confused how this test passes for both Günter and Kornel, >> >> >> > > but not me. I am using the noto fonts from the Ubuntu >> >> >> > > packages. Perhaps you two are using newer versions of them from >> >> >> > > upstream? Could that explain the differences we see? >> >> >> > >> >> >> > Maybe. Here, I have NotoSerifLao.otf version 1.03 from the package >> >> >> > fonts-noto-hinted (Debian/stable) Version: 20161116-1 >> >> >> > and there is no missing character. >> >> ... >> >> Sorry the "otf" was my mistake, same here: >> ... >> >> /usr/share/fonts/truetype/noto/NotoSerifLao-Bold.ttf >> >> /usr/share/fonts/truetype/noto/NotoSerifLao-Regular.ttf >> >> > I am just making theories at this point, but perhaps the period was >> >> > removed in the newer version of the font, ... >> ... >> > The version shows as "2.000". >> So, indeed the punctuation was removed (despite beeing used in Lao wikipedia >> texts). > That does seem like a strange change. Perhaps the next version will > change it back. I don't think so ... >> ... browsers or OpenOffice automatically >> substitute missing characters when displaying a text: The Noto fonts are >> split into smaller files and programs are expected to pick glyphs from the file set (instead of beeing given a single font file). This adds flexibility and avoids huge font files where most glyphs are never used. Maybe LuaTeX/fontspec will support this way of font use one day... Günter
Re: languages and fonts
On 2019-09-04, Kornel Benko wrote:
> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
>> Please try the updated "supported-languages" tests.
> 399 -
> DEFAULTOUTPUT_export/export/latex/languages/supported-languages_polyglossia-XeTeX_pdf4_systemF
> (Failed)
> LaTeX.cpp (742): Log line: ! Package fontspec Error: The font "Noto Serif
> Devanagari" cannot be found.
> LaTeX.cpp (972): line: 66
> Desc: Package fontspec Error: The font "Noto Serif Devanagari" cannot be
> found.
> Text: \newfontfamily
>\hangulfont{Baekmuk Batang}
> LaTeX.cpp (742): Log line: A font might not be found for many reasons.
> LaTeX.cpp (742): Log line: Check the spelling, where the font is installed
> etc. etc.
> It is passing with 'Noto Sans Devanagari'
However, as Noto Devenagari exists in two families, Serif and Sans
using Noto Sans Devenagari as "roman" font for Devenagari is not correct.
In Debian, both "Noto * Devenagari" fonts are part of the "fonts-noto-core"
package since "Debian/buster".
Alternatively, you can download from
https://noto-website-2.storage.googleapis.com/pkgs/NotoSerif-hinted.zip
and unpack into ~/.fonts .
Günter
Re: Is it possible to get transparent cursors?
On 2019-09-04 16:01, Jean-Marc Lasgouttes wrote: Le 04/09/2019 à 15:57, Daniel a écrit : On 2019-09-03 01:12, Jason Sun wrote: I tried to use a bigger cursor but the cursor blocks the text if I do so, making it a bit annoying.. Is there an option to make the cursor transparent with the current implementation? I am curious what a transparent cursor would be useful for. How would you see where the current cursor position is? Transparent doe snot mean invisible... JMarc Strictly speaking true but it does mean fully transparent, at least in some design context, e.g. CSS: "The transparent keyword represents a fully transparent color. This makes the background behind the colored item completely visible. Technically, transparent is a shortcut for rgba(0,0,0,0)." (https://developer.mozilla.org/en-US/docs/Web/CSS/color_value) But I guess Jason means semi-transparent or so. Anyway, I am still a fan of colour inversion. :) Daniel
Re: Notes inherit surrounding font
On 9/4/19 10:30 AM, Jean-Marc Lasgouttes wrote: > Le 24/08/2019 à 07:49, Daniel a écrit : >> Currently, IMO, notes behave in an unfortunate way in that they >> inherit the surrounding font. >> >> Consider the attached document which has the following structure: >> >> *Section* >> Text >> >> The first line is formatted as a section heading and the second as >> standard text. >> >> In Lyx, select all text in the document and insert a note. >> >> The actual result is that all the text looks as if it where formatted >> as section. This is misleading. It is also in many cases annoying. >> For example, when adding a longer note to a section heading it >> becomes huge. > > This is not misleading. I don't know if it's misleading, but I find it slightly annoying that the font of the note is so huge. I might want a note in a non-empty section heading to remind me of something, but I don't need it to be the same size as the heading itself. There's no real need for it to be, either. Riki
Re: languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
On Wed, Sep 04, 2019 at 03:04:35PM +0200, Kornel Benko wrote:
> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
> > On 2019-09-04, Scott Kostyshak wrote:
> > > On Tue, Sep 03, 2019 at 09:23:54PM -, Guenter Milde wrote:
> > >> On 2019-09-03, Scott Kostyshak wrote:
> > >> > On Mon, Sep 02, 2019 at 10:01:13PM -0400, Scott Kostyshak wrote:
> >
> > ...
> >
> > >> >> > > I still have a "Missing character" error as follows:
> > >> >> >
> > >> >> > > There is no . in font Noto Serif Lao
> > >> >> > > Regular/OT:script=lao;l
> > >> >> >
> > >> >> > > I'm confused how this test passes for both Günter and Kornel,
> > >> >> > > but not me. I am using the noto fonts from the Ubuntu
> > >> >> > > packages. Perhaps you two are using newer versions of them from
> > >> >> > > upstream? Could that explain the differences we see?
> > >> >> >
> > >> >> > Maybe. Here, I have NotoSerifLao.otf version 1.03 from the package
> > >> >> > fonts-noto-hinted (Debian/stable) Version: 20161116-1
> > >> >> > and there is no missing character.
> > >> ...
> > >> Sorry the "otf" was my mistake, same here:
> > ...
> > >> /usr/share/fonts/truetype/noto/NotoSerifLao-Bold.ttf
> > >> /usr/share/fonts/truetype/noto/NotoSerifLao-Regular.ttf
> >
> >
> > >> > I am just making theories at this point, but perhaps the period was
> > >> > removed in the newer version of the font, ...
> >
> > ...
> >
> > > The version shows as "2.000".
> >
> > So, indeed the punctuation was removed (despite beeing used in Lao wikipedia
> > texts).
> >
> > This is OK for many use case, where browsers or OpenOffice automatically
> > substitute missing characters when displaying a text: The Noto fonts are
> > split into smaller files with glyphs of a specific script intended to be
> > used together.
> >
> > However, in Xe- and LuaTeX, there is no such automatic replacement, as this
> > can lead to inferiour typographical results (mis-match of type styles).
> > This makes the Noto fonts unsuited for TeX.
> > Hopefully, in future LuaTeX will offer to define substitution fonts, but for
> > now this would require every full stop to be written in a different language
> > than the running Lao text :(
> >
> > Fortunately, DejaVu contains a large set of characters, including Lao.
> >
> > Please try the updated "supported-languages" tests.
> >
> > Günter
> >
> 399 -
> DEFAULTOUTPUT_export/export/latex/languages/supported-languages_polyglossia-XeTeX_pdf4_systemF
> (Failed)
>
> LaTeX.cpp (742): Log line: ! Package fontspec Error: The font "Noto Serif
> Devanagari" cannot be found.
> LaTeX.cpp (972): line: 66
> Desc: Package fontspec Error: The font "Noto Serif Devanagari" cannot be
> found.
> Text: \newfontfamily
>\hangulfont{Baekmuk Batang}
>
> LaTeX.cpp (742): Log line: A font might not be found for many reasons.
> LaTeX.cpp (742): Log line: Check the spelling, where the font is installed
> etc. etc.
>
>
> It is passing with 'Noto Sans Devanagari'
I do not get the above error. I have the following:
/usr/share/fonts/truetype/noto/NotoSansDevanagari-Regular.ttf
/usr/share/fonts/truetype/noto/NotoSerifDevanagari-Regular.ttf
Strangely, the test fails for me, but when I compile manually it passes.
Scott
signature.asc
Description: PGP signature
Re: Notes inherit surrounding font
Le 24/08/2019 à 07:49, Daniel a écrit :
Currently, IMO, notes behave in an unfortunate way in that they inherit
the surrounding font.
Consider the attached document which has the following structure:
*Section*
Text
The first line is formatted as a section heading and the second as
standard text.
In Lyx, select all text in the document and insert a note.
The actual result is that all the text looks as if it where formatted as
section. This is misleading. It is also in many cases annoying. For
example, when adding a longer note to a section heading it becomes huge.
This is not misleading. This indicates that your note is actuall
embedded in a paragraph with style Section, so that the empty paragraph
will be output as
\section{]
This is the behavior that we shall fix.
I propose in the following patch to reset the outer layout to Plain if
it only contains the newly insert inset.
I'd appreciate if somebody could try t out to see whether I missed
something obvious. This behavior has been annoying me for ages and I am
sure we have several bug reports about that.
JMarc
From 68872c28ebf8c479e08580d4b5f785f5c99f9561 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Wed, 4 Sep 2019 16:13:22 +0200
Subject: [PATCH] Reset layout when inserting an inset over full paragraph(s)
When inserting an inset over a selection, it makes sense if the
selection covers a complete or several paragraphs to reset the layout of
the paragraph that contains the inset to plain layout. In general the
inner inset will have the needed layout information and it does not
make sense to keep this information outside.
Note that this does not work as intended when change tracking is enabled.
---
src/Text3.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/Text3.cpp b/src/Text3.cpp
index 57d44a1..0ba8083 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -293,11 +293,22 @@ static bool doInsertInset(Cursor & cur, Text * text,
}
bool gotsel = false;
+ bool reset_layout = false;
if (cur.selection()) {
if (cmd.action() == LFUN_INDEX_INSERT)
copySelectionToTemp(cur);
- else
+ else {
cutSelectionToTemp(cur, pastesel);
+ /* No need to keep layout information if the inset has
+ * eaten the whole paragraph.
+ * FIXME: this does not work as expected when change tracking is on
+ * However, we do not really know what to do in this case.
+ */
+ if (cur.paragraph().empty()) {
+cur.paragraph().setPlainOrDefaultLayout(bparams.documentClass());
+reset_layout = true;
+ }
+ }
cur.clearSelection();
gotsel = true;
} else if (cmd.action() == LFUN_INDEX_INSERT) {
@@ -320,7 +331,8 @@ static bool doInsertInset(Cursor & cur, Text * text,
InsetText * inset_text = inset->asInsetText();
if (inset_text) {
inset_text->fixParagraphsFont();
- if (!inset_text->allowMultiPar() || cur.lastpit() == 0) {
+ if (!inset_text->allowMultiPar()
+ || (cur.lastpit() == 0 && !reset_layout)) {
// reset first par to default
cur.text()->paragraphs().begin()
->setPlainOrDefaultLayout(bparams.documentClass());
--
2.7.4
Re: Is it possible to get transparent cursors?
Le 04/09/2019 à 15:57, Daniel a écrit : On 2019-09-03 01:12, Jason Sun wrote: I tried to use a bigger cursor but the cursor blocks the text if I do so, making it a bit annoying.. Is there an option to make the cursor transparent with the current implementation? I am curious what a transparent cursor would be useful for. How would you see where the current cursor position is? Transparent doe snot mean invisible... JMarc
Re: Is it possible to get transparent cursors?
On 2019-09-03 01:12, Jason Sun wrote: I tried to use a bigger cursor but the cursor blocks the text if I do so, making it a bit annoying.. Is there an option to make the cursor transparent with the current implementation? I am curious what a transparent cursor would be useful for. How would you see where the current cursor position is? As for the cursor blocking text, would a cursor that inverts the colors beneth it help? I suggested this and a patch a while back: https://www.lyx.org/trac/ticket/10462 Daniel
Re: Is it possible to get transparent cursors?
Le 03/09/2019 à 01:12, Jason Sun a écrit : I tried to use a bigger cursor but the cursor blocks the text if I do so, making it a bit annoying.. Is there an option to make the cursor transparent with the current implementation? We do not support transparent colors right now. This would not be very difficult, but some work has to be done for that. JMarc
Re: esint10.tfm missing in TL19
On Wed, Sep 04, 2019 at 03:09:27PM +0200, Kornel Benko wrote: > Am Mittwoch, 4. September 2019, 08:59:48 CEST schrieb Scott Kostyshak: > > On Wed, Sep 04, 2019 at 12:25:25PM +0200, Kornel Benko wrote: > > > Am Dienstag, 3. September 2019, 21:56:03 CEST schrieb Scott Kostyshak: > > > > On Tue, Sep 03, 2019 at 09:06:53PM -, Guenter Milde wrote: > > > > > > > > > This may be related (even if it is hard to tell how). > > > > > > > > > > It would be nice to keep this in mind and start commenting out the > > > > > various > > > > > included to narrow down the problematic package or code. > > > > > > > > Attached is a minimal example. Does compilation of this example file > > > > with LuaTeX and TeX fonts fail for others who have an updated TL? > > > > > > > > Scott > > > > > > > > > > Compiles fine here with todays TL19. > > > > That suggests there might be something wrong with my installation. Can > > you send me the log that you get with that MWE with LuaTeX and TeX > > fonts? > > > > Thanks, > > > > Scott > > > > Sent privately. Got it. I'll take a look tonight (when I have access to my computer with an updated TL). I wonder if I accidentally have some old package version hanging around or something like that. Thanks, Scott signature.asc Description: PGP signature
Re: Some exports are currently failing on master
On Wed, Sep 04, 2019 at 12:56:57PM -, Guenter Milde wrote: > On 2019-08-29, Scott Kostyshak wrote: > > On Thu, Aug 29, 2019 at 12:20:56PM -, Guenter Milde wrote: > > ... > >> I did not follow this and never use preview, so how can I reproduce? > > > First enable preview by doing > > > Tools > Preferences > Display > and set Instant preview to "On" > > > Then, save the preferences and exit LyX. Then, just open the following > > file in LyX from the terminal: > > > lyx lib/examples/es/Modules/Linguistics.lyx > > > I get the messages (without doing anything) after 3 seconds. > > > Can you reproduce? > > I can reproduce. > > Please try the patch below (the idea is to keep the "filter_pages()" > function "encoding-agnostic" by using byte-strings): > > * Save the mail (in mbox or text format) to "/tmp/preview.patch", say. > > * In the repo: > >git apply /tmp/preview.patch > > * Test. Tested and it works well: the terminal messages are gone and the preview (just before Section 7) shows up and looks good to me. Thanks, Scott signature.asc Description: PGP signature
Re: [PATCH] Port gnuplot2pdf.py to Python 3
On Wed, Sep 04, 2019 at 12:24:40PM -, Guenter Milde wrote: > On 2019-08-30, Scott Kostyshak wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > The current script fails for me. The attached patch seems to work, but I > > only got it to work by experimenting. Can any Pythonista take a close > > look? With the wait() command it seems to hang, so I substituted > > communicate() as mentioned here: > > > https://docs.python.org/3/library/subprocess.html > > The patch looks fine to me. Thanks for taking a look. Committed to master at db65b1a3. Scott signature.asc Description: PGP signature
Re: esint10.tfm missing in TL19
Am Mittwoch, 4. September 2019, 08:59:48 CEST schrieb Scott Kostyshak: > On Wed, Sep 04, 2019 at 12:25:25PM +0200, Kornel Benko wrote: > > Am Dienstag, 3. September 2019, 21:56:03 CEST schrieb Scott Kostyshak: > > > On Tue, Sep 03, 2019 at 09:06:53PM -, Guenter Milde wrote: > > > > > > > This may be related (even if it is hard to tell how). > > > > > > > > It would be nice to keep this in mind and start commenting out the > > > > various > > > > included to narrow down the problematic package or code. > > > > > > Attached is a minimal example. Does compilation of this example file > > > with LuaTeX and TeX fonts fail for others who have an updated TL? > > > > > > Scott > > > > > > > Compiles fine here with todays TL19. > > That suggests there might be something wrong with my installation. Can > you send me the log that you get with that MWE with LuaTeX and TeX > fonts? > > Thanks, > > Scott > Sent privately. Kornel signature.asc Description: This is a digitally signed message part.
Re: languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
> On 2019-09-04, Scott Kostyshak wrote:
> > On Tue, Sep 03, 2019 at 09:23:54PM -, Guenter Milde wrote:
> >> On 2019-09-03, Scott Kostyshak wrote:
> >> > On Mon, Sep 02, 2019 at 10:01:13PM -0400, Scott Kostyshak wrote:
>
> ...
>
> >> >> > > I still have a "Missing character" error as follows:
> >> >> >
> >> >> > > There is no . in font Noto Serif Lao
> >> >> > > Regular/OT:script=lao;l
> >> >> >
> >> >> > > I'm confused how this test passes for both Günter and Kornel,
> >> >> > > but not me. I am using the noto fonts from the Ubuntu
> >> >> > > packages. Perhaps you two are using newer versions of them from
> >> >> > > upstream? Could that explain the differences we see?
> >> >> >
> >> >> > Maybe. Here, I have NotoSerifLao.otf version 1.03 from the package
> >> >> > fonts-noto-hinted (Debian/stable) Version: 20161116-1
> >> >> > and there is no missing character.
> >> ...
> >> Sorry the "otf" was my mistake, same here:
> ...
> >> /usr/share/fonts/truetype/noto/NotoSerifLao-Bold.ttf
> >> /usr/share/fonts/truetype/noto/NotoSerifLao-Regular.ttf
>
>
> >> > I am just making theories at this point, but perhaps the period was
> >> > removed in the newer version of the font, ...
>
> ...
>
> > The version shows as "2.000".
>
> So, indeed the punctuation was removed (despite beeing used in Lao wikipedia
> texts).
>
> This is OK for many use case, where browsers or OpenOffice automatically
> substitute missing characters when displaying a text: The Noto fonts are
> split into smaller files with glyphs of a specific script intended to be
> used together.
>
> However, in Xe- and LuaTeX, there is no such automatic replacement, as this
> can lead to inferiour typographical results (mis-match of type styles).
> This makes the Noto fonts unsuited for TeX.
> Hopefully, in future LuaTeX will offer to define substitution fonts, but for
> now this would require every full stop to be written in a different language
> than the running Lao text :(
>
> Fortunately, DejaVu contains a large set of characters, including Lao.
>
> Please try the updated "supported-languages" tests.
>
> Günter
>
399 -
DEFAULTOUTPUT_export/export/latex/languages/supported-languages_polyglossia-XeTeX_pdf4_systemF
(Failed)
LaTeX.cpp (742): Log line: ! Package fontspec Error: The font "Noto Serif
Devanagari" cannot be found.
LaTeX.cpp (972): line: 66
Desc: Package fontspec Error: The font "Noto Serif Devanagari" cannot be found.
Text: \newfontfamily
\hangulfont{Baekmuk Batang}
LaTeX.cpp (742): Log line: A font might not be found for many reasons.
LaTeX.cpp (742): Log line: Check the spelling, where the font is installed
etc. etc.
It is passing with 'Noto Sans Devanagari'
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
On Wed, Sep 04, 2019 at 12:02:02PM -, Guenter Milde wrote: > On 2019-09-04, Scott Kostyshak wrote: > > On Tue, Sep 03, 2019 at 09:23:54PM -, Guenter Milde wrote: > >> On 2019-09-03, Scott Kostyshak wrote: > >> > On Mon, Sep 02, 2019 at 10:01:13PM -0400, Scott Kostyshak wrote: > > ... > > >> >> > > I still have a "Missing character" error as follows: > >> >> > > >> >> > > There is no . in font Noto Serif Lao > >> >> > > Regular/OT:script=lao;l > >> >> > > >> >> > > I'm confused how this test passes for both Günter and Kornel, > >> >> > > but not me. I am using the noto fonts from the Ubuntu > >> >> > > packages. Perhaps you two are using newer versions of them from > >> >> > > upstream? Could that explain the differences we see? > >> >> > > >> >> > Maybe. Here, I have NotoSerifLao.otf version 1.03 from the package > >> >> > fonts-noto-hinted (Debian/stable) Version: 20161116-1 > >> >> > and there is no missing character. > >> ... > >> Sorry the "otf" was my mistake, same here: > ... > >> /usr/share/fonts/truetype/noto/NotoSerifLao-Bold.ttf > >> /usr/share/fonts/truetype/noto/NotoSerifLao-Regular.ttf > > > >> > I am just making theories at this point, but perhaps the period was > >> > removed in the newer version of the font, ... > > ... > > > The version shows as "2.000". > > So, indeed the punctuation was removed (despite beeing used in Lao wikipedia > texts). That does seem like a strange change. Perhaps the next version will change it back. > This is OK for many use case, where browsers or OpenOffice automatically > substitute missing characters when displaying a text: The Noto fonts are > split into smaller files with glyphs of a specific script intended to be > used together. > > However, in Xe- and LuaTeX, there is no such automatic replacement, as this > can lead to inferiour typographical results (mis-match of type styles). > This makes the Noto fonts unsuited for TeX. > Hopefully, in future LuaTeX will offer to define substitution fonts, but for > now this would require every full stop to be written in a different language > than the running Lao text :( > > Fortunately, DejaVu contains a large set of characters, including Lao. > > Please try the updated "supported-languages" tests. I will try this when I get home. Thanks, Scott signature.asc Description: PGP signature
Re: esint10.tfm missing in TL19
On Wed, Sep 04, 2019 at 12:25:25PM +0200, Kornel Benko wrote: > Am Dienstag, 3. September 2019, 21:56:03 CEST schrieb Scott Kostyshak: > > On Tue, Sep 03, 2019 at 09:06:53PM -, Guenter Milde wrote: > > > > > This may be related (even if it is hard to tell how). > > > > > > It would be nice to keep this in mind and start commenting out the various > > > included to narrow down the problematic package or code. > > > > Attached is a minimal example. Does compilation of this example file > > with LuaTeX and TeX fonts fail for others who have an updated TL? > > > > Scott > > > > Compiles fine here with todays TL19. That suggests there might be something wrong with my installation. Can you send me the log that you get with that MWE with LuaTeX and TeX fonts? Thanks, Scott signature.asc Description: PGP signature
Re: Some exports are currently failing on master
On 2019-08-29, Scott Kostyshak wrote:
> On Thu, Aug 29, 2019 at 12:20:56PM -, Guenter Milde wrote:
...
>> I did not follow this and never use preview, so how can I reproduce?
> First enable preview by doing
> Tools > Preferences > Display > and set Instant preview to "On"
> Then, save the preferences and exit LyX. Then, just open the following
> file in LyX from the terminal:
> lyx lib/examples/es/Modules/Linguistics.lyx
> I get the messages (without doing anything) after 3 seconds.
> Can you reproduce?
I can reproduce.
Please try the patch below (the idea is to keep the "filter_pages()"
function "encoding-agnostic" by using byte-strings):
* Save the mail (in mbox or text format) to "/tmp/preview.patch", say.
* In the repo:
git apply /tmp/preview.patch
* Test.
Thanks,
Günter
Exec: git 'diff' 'lyxpreview_tools.py' 2>&1
Dir: /usr/local/src/lyx/lib/scripts/
diff --git a/lib/scripts/lyxpreview_tools.py b/lib/scripts/lyxpreview_tools.py
index 91cc4d6ab1..2f8c2f8d64 100644
--- a/lib/scripts/lyxpreview_tools.py
+++ b/lib/scripts/lyxpreview_tools.py
@@ -219,16 +219,16 @@ def write_metrics_info(metrics_info, metrics_file):
# Reads a .tex files and create an identical file but only with
# pages whose index is in pages_to_keep
def filter_pages(source_path, destination_path, pages_to_keep):
-def_re =
re.compile(r"(\\newcommandx|\\renewcommandx|\\global\\long\\def)(\\[a-zA-Z]+)(.+)")
-source_file = open(source_path, "r")
-destination_file = open(destination_path, "w")
+def_re =
re.compile(rb"(\\newcommandx|\\renewcommandx|\\global\\long\\def)(\\[a-zA-Z]+)(.+)")
+source_file = open(source_path, "rb")
+destination_file = open(destination_path, "wb")
page_index = 0
skip_page = False
macros = []
for line in source_file:
# We found a new page
-if line.startswith("\\begin{preview}"):
+if line.startswith(b"\\begin{preview}"):
page_index += 1
# If the page index isn't in pages_to_keep we don't copy it
skip_page = page_index not in pages_to_keep
@@ -240,12 +240,12 @@ def filter_pages(source_path, destination_path,
pages_to_keep):
macroname = match.group(2)
if not macroname in macros:
macros.append(macroname)
-if definecmd == "\\renewcommandx":
-line = line.replace(definecmd, "\\newcommandx")
+if definecmd == b"\\renewcommandx":
+line = line.replace(definecmd, b"\\newcommandx")
destination_file.write(line)
# End of a page, we reset the skip_page bool
-if line.startswith("\\end{preview}"):
+if line.startswith(b"\\end{preview}"):
skip_page = False
destination_file.close()
Re: [PATCH] Port gnuplot2pdf.py to Python 3
On 2019-08-30, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > The current script fails for me. The attached patch seems to work, but I > only got it to work by experimenting. Can any Pythonista take a close > look? With the wait() command it seems to hang, so I substituted > communicate() as mentioned here: > https://docs.python.org/3/library/subprocess.html The patch looks fine to me. Thanks, Günter
languages and fonts: Lao (was: supported-languages_polyglossia.lyx: should NotoSansEthiopic have spaces?)
On 2019-09-04, Scott Kostyshak wrote: > On Tue, Sep 03, 2019 at 09:23:54PM -, Guenter Milde wrote: >> On 2019-09-03, Scott Kostyshak wrote: >> > On Mon, Sep 02, 2019 at 10:01:13PM -0400, Scott Kostyshak wrote: ... >> >> > > I still have a "Missing character" error as follows: >> >> > >> >> > > There is no . in font Noto Serif Lao >> >> > > Regular/OT:script=lao;l >> >> > >> >> > > I'm confused how this test passes for both Günter and Kornel, >> >> > > but not me. I am using the noto fonts from the Ubuntu >> >> > > packages. Perhaps you two are using newer versions of them from >> >> > > upstream? Could that explain the differences we see? >> >> > >> >> > Maybe. Here, I have NotoSerifLao.otf version 1.03 from the package >> >> > fonts-noto-hinted (Debian/stable) Version: 20161116-1 >> >> > and there is no missing character. >> ... >> Sorry the "otf" was my mistake, same here: ... >> /usr/share/fonts/truetype/noto/NotoSerifLao-Bold.ttf >> /usr/share/fonts/truetype/noto/NotoSerifLao-Regular.ttf >> > I am just making theories at this point, but perhaps the period was >> > removed in the newer version of the font, ... ... > The version shows as "2.000". So, indeed the punctuation was removed (despite beeing used in Lao wikipedia texts). This is OK for many use case, where browsers or OpenOffice automatically substitute missing characters when displaying a text: The Noto fonts are split into smaller files with glyphs of a specific script intended to be used together. However, in Xe- and LuaTeX, there is no such automatic replacement, as this can lead to inferiour typographical results (mis-match of type styles). This makes the Noto fonts unsuited for TeX. Hopefully, in future LuaTeX will offer to define substitution fonts, but for now this would require every full stop to be written in a different language than the running Lao text :( Fortunately, DejaVu contains a large set of characters, including Lao. Please try the updated "supported-languages" tests. Günter
Re: esint10.tfm missing in TL19
Am Dienstag, 3. September 2019, 21:56:03 CEST schrieb Scott Kostyshak: > On Tue, Sep 03, 2019 at 09:06:53PM -, Guenter Milde wrote: > > > This may be related (even if it is hard to tell how). > > > > It would be nice to keep this in mind and start commenting out the various > > included to narrow down the problematic package or code. > > Attached is a minimal example. Does compilation of this example file > with LuaTeX and TeX fonts fail for others who have an updated TL? > > Scott > Compiles fine here with todays TL19. Kornel signature.asc Description: This is a digitally signed message part.
