Re: [LyX/master] Properly implement CJKutf8

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 14:34 +0100 schrieb Juergen Spitzmueller:
> commit d193cd05a8e3be92e34a873416a16c2a474b61cb
> Author: Juergen Spitzmueller 
> Date:   Sun Jan 6 14:36:11 2019 +0100
> 
> Properly implement CJKutf8
> 
> If we use that, the document actually needs to be in utf8
> encoding, and
> the CJK environment needs to account for it.
> 
 
Riki, this is a candidate for stable (together with c9dd349bee71d).

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Montag, den 07.01.2019, 06:45 +0100 schrieb Kornel Benko:
> Thanks Jürgen and Scott, works as expected.
> What about to make it compilable for xetex and luatex too?
> Since 'mj' refers to 'myeongjo', the attached seems appropriate.

Good idea.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Scott Kostyshak]

On Mon, Jan 07, 2019 at 06:45:58AM +0100, Kornel Benko wrote:
> Am Sonntag, 6. Januar 2019 14:51:54 CET schrieb Scott Kostyshak 
> :
> > On Sun, Jan 06, 2019 at 08:15:20PM +0100, Kornel Benko wrote:
> > > Am Sonntag, 6. Januar 2019 14:03:37 CET schrieb Scott Kostyshak 
> > > :
> > > > On Sun, Jan 06, 2019 at 07:46:03PM +0100, Jürgen Spitzmüller wrote:
> > > > > Am Sonntag, den 06.01.2019, 13:39 -0500 schrieb Scott Kostyshak:
> > > > > > Nice! Thanks for implementing that, Jürgen. It would be great for it
> > > > > > to
> > > > > > compile with pdfTeX out of the box. I get the same error as
> > > > > > Kornel.  I
> > > > > > will search for more information on the map file and how to enable
> > > > > > it.
> > > > > 
> > > > > Does it work for you if you insert "mj" into Document > Settings >
> > > > > Fonts > CJK?
> > > > > 
> > > > > This seems to be the recommended font.
> > > > 
> > > > Yes, that works well. With that change, the test output looks good.
> > > > 
> > > > Scott
> > > 
> > > Works here too.
> > 
> > Tests uninverted at 9238004c.
> > 
> > Scott
> 
> Thanks Jürgen and Scott, works as expected.
> What about to make it compilable for xetex and luatex too?
> Since 'mj' refers to 'myeongjo', the attached seems appropriate.

Makes sense. It seems we also set fonts for the Greek intro, so this
would be consistent with that.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 14:51:54 CET schrieb Scott Kostyshak 
:
> On Sun, Jan 06, 2019 at 08:15:20PM +0100, Kornel Benko wrote:
> > Am Sonntag, 6. Januar 2019 14:03:37 CET schrieb Scott Kostyshak 
> > :
> > > On Sun, Jan 06, 2019 at 07:46:03PM +0100, Jürgen Spitzmüller wrote:
> > > > Am Sonntag, den 06.01.2019, 13:39 -0500 schrieb Scott Kostyshak:
> > > > > Nice! Thanks for implementing that, Jürgen. It would be great for it
> > > > > to
> > > > > compile with pdfTeX out of the box. I get the same error as
> > > > > Kornel.  I
> > > > > will search for more information on the map file and how to enable
> > > > > it.
> > > > 
> > > > Does it work for you if you insert "mj" into Document > Settings >
> > > > Fonts > CJK?
> > > > 
> > > > This seems to be the recommended font.
> > > 
> > > Yes, that works well. With that change, the test output looks good.
> > > 
> > > Scott
> > 
> > Works here too.
> 
> Tests uninverted at 9238004c.
> 
> Scott

Thanks Jürgen and Scott, works as expected.
What about to make it compilable for xetex and luatex too?
Since 'mj' refers to 'myeongjo', the attached seems appropriate.

Kornel

diff --git a/lib/examples/ko/splash.lyx b/lib/examples/ko/splash.lyx
index 61466f2..831f6bb 100644
--- a/lib/examples/ko/splash.lyx
+++ b/lib/examples/ko/splash.lyx
@@ -9,13 +9,13 @@
 \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" "NanumMyeongjo"
+\font_sans "default" "NanumGothic"
+\font_typewriter "default" "NanumGothicCoding"
 \font_math "auto" "auto"
 \font_default_family default
 \use_non_tex_fonts false
 \font_sc false
 \font_osf false


signature.asc
Description: This is a digitally signed message part.

Re: #11369: Mac Initialization error

[Roger]

Reconfigure triggers the problem.
However, it does not cause a permanent problem.
When the error message caused by Reconfigure occurs I have to quit LyX using 
the Dock icon after which LyX starts OK.
There is only one Lyx folder in ~/Library/Applications Support.
However, if needed I can probably find an earlier version with Time Machine.
Regards,
Roger



> On 7 Jan 2019, at 10:50 am, LyX Ticket Tracker  wrote:
> 
> #11369: Mac Initialization error
> --+---
> Reporter:  rogermc   |   Owner:  skostysh
> Type:  defect|  Status:  new
> Priority:  normal|   Milestone:
> Component:  frontend-qt5  | Version:  2.3.1
> Severity:  blocker   |  Resolution:
> Keywords:  os=macosx |
> --+---
> 
> Comment (by stwitt):
> 
> I think the problem is not solved. To investigate further I'd like to
> know:
> 1. Are you able to trigger the problem by running Reconfigure (Tools
> menu)?
> 2. Can you check for differences between the two versions of the Lyx-2.3
> folder from Applications Support?
> 
> -- 
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor

Re: [LyX/master] Add comment.

[Scott Kostyshak]

On Sun, Jan 06, 2019 at 05:51:37PM -0500, Richard Kimberly Heck wrote:
> On 1/6/19 4:47 PM, Scott Kostyshak wrote:
> > On Sun, Jan 06, 2019 at 06:59:59PM +0100, Richard Kimberly Heck wrote:
> >> commit b35d90014ec5f37863679fc4ef4a2a67c87b4c64
> >> Author: Richard Kimberly Heck 
> >> Date:   Sun Jan 6 13:02:40 2019 -0500
> >>
> >> Add comment.
> >> ---
> >>  src/frontends/qt4/GuiRef.cpp |2 ++
> >>  1 files changed, 2 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/src/frontends/qt4/GuiRef.cpp b/src/frontends/qt4/GuiRef.cpp
> >> index 5d46a47..792b852 100644
> >> --- a/src/frontends/qt4/GuiRef.cpp
> >> +++ b/src/frontends/qt4/GuiRef.cpp
> >> @@ -323,6 +323,8 @@ void GuiRef::updateContents()
> >>  
> >>// FIXME Bring InsetMathRef on par with InsetRef
> >>// (see #9798)
> >> +  // NOTE: The order here must be kept in sync with the defintion
> >> +  // of the types[] array in InsetRef.cpp.
> >>typeCO->addItem(qt_(""), "ref");
> >>typeCO->addItem(qt_("()"), "eqref");
> >>typeCO->addItem(qt_(""), "pageref");
> > Why must the order be kept in sync? Just to provide a consistent
> > interface for the user, or is there an implementation reason? 
> 
> I found this out myself rather late. See 9b3f9cc6. We look up things in
> the types[] array using indices gotten from the combo box. I didn't
> realize that, and it broke some code. The problem, basically, is that we
> cannot use the text in the combobox to figure out what the setting is,
> because that might be translated.
> 
> On second thought, though I actually think we don't need to do that. The
> getType routine is unnecessary and just bad. Which frees you up to do as
> you wish.

Nice, that seems to simplify things.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Add comment.

[Richard Kimberly Heck]

On 1/6/19 4:47 PM, Scott Kostyshak wrote:
> On Sun, Jan 06, 2019 at 06:59:59PM +0100, Richard Kimberly Heck wrote:
>> commit b35d90014ec5f37863679fc4ef4a2a67c87b4c64
>> Author: Richard Kimberly Heck 
>> Date:   Sun Jan 6 13:02:40 2019 -0500
>>
>> Add comment.
>> ---
>>  src/frontends/qt4/GuiRef.cpp |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/frontends/qt4/GuiRef.cpp b/src/frontends/qt4/GuiRef.cpp
>> index 5d46a47..792b852 100644
>> --- a/src/frontends/qt4/GuiRef.cpp
>> +++ b/src/frontends/qt4/GuiRef.cpp
>> @@ -323,6 +323,8 @@ void GuiRef::updateContents()
>>  
>>  // FIXME Bring InsetMathRef on par with InsetRef
>>  // (see #9798)
>> +// NOTE: The order here must be kept in sync with the defintion
>> +// of the types[] array in InsetRef.cpp.
>>  typeCO->addItem(qt_(""), "ref");
>>  typeCO->addItem(qt_("()"), "eqref");
>>  typeCO->addItem(qt_(""), "pageref");
> Why must the order be kept in sync? Just to provide a consistent
> interface for the user, or is there an implementation reason? 

I found this out myself rather late. See 9b3f9cc6. We look up things in
the types[] array using indices gotten from the combo box. I didn't
realize that, and it broke some code. The problem, basically, is that we
cannot use the text in the combobox to figure out what the setting is,
because that might be translated.

On second thought, though I actually think we don't need to do that. The
getType routine is unnecessary and just bad. Which frees you up to do as
you wish.

Riki

Re: [LyX/master] Add comment.

[Scott Kostyshak]

On Sun, Jan 06, 2019 at 06:59:59PM +0100, Richard Kimberly Heck wrote:
> commit b35d90014ec5f37863679fc4ef4a2a67c87b4c64
> Author: Richard Kimberly Heck 
> Date:   Sun Jan 6 13:02:40 2019 -0500
> 
> Add comment.
> ---
>  src/frontends/qt4/GuiRef.cpp |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/src/frontends/qt4/GuiRef.cpp b/src/frontends/qt4/GuiRef.cpp
> index 5d46a47..792b852 100644
> --- a/src/frontends/qt4/GuiRef.cpp
> +++ b/src/frontends/qt4/GuiRef.cpp
> @@ -323,6 +323,8 @@ void GuiRef::updateContents()
>  
>   // FIXME Bring InsetMathRef on par with InsetRef
>   // (see #9798)
> + // NOTE: The order here must be kept in sync with the defintion
> + // of the types[] array in InsetRef.cpp.
>   typeCO->addItem(qt_(""), "ref");
>   typeCO->addItem(qt_("()"), "eqref");
>   typeCO->addItem(qt_(""), "pageref");

Why must the order be kept in sync? Just to provide a consistent
interface for the user, or is there an implementation reason? I'm
working on a patch that will automatically order them according to how
they're ordered by the types[] array (I'm more doing this as a little
self-study C++ exercise; I'm not sure the patch will be worth
including).

Also, why is "prettyref" not included in InsetRef::types?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Scott Kostyshak]

On Sun, Jan 06, 2019 at 08:15:20PM +0100, Kornel Benko wrote:
> Am Sonntag, 6. Januar 2019 14:03:37 CET schrieb Scott Kostyshak 
> :
> > On Sun, Jan 06, 2019 at 07:46:03PM +0100, Jürgen Spitzmüller wrote:
> > > Am Sonntag, den 06.01.2019, 13:39 -0500 schrieb Scott Kostyshak:
> > > > Nice! Thanks for implementing that, Jürgen. It would be great for it
> > > > to
> > > > compile with pdfTeX out of the box. I get the same error as
> > > > Kornel.  I
> > > > will search for more information on the map file and how to enable
> > > > it.
> > > 
> > > Does it work for you if you insert "mj" into Document > Settings >
> > > Fonts > CJK?
> > > 
> > > This seems to be the recommended font.
> > 
> > Yes, that works well. With that change, the test output looks good.
> > 
> > Scott
> 
> Works here too.

Tests uninverted at 9238004c.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Scott Kostyshak]

On Sun, Jan 06, 2019 at 08:05:23PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 06.01.2019, 14:03 -0500 schrieb Scott Kostyshak:
> > Yes, that works well. With that change, the test output looks good.
> 
> Good. Would you commit this change, please?

Done at 0cfaf406.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: define LYX_USE_LONG_LONG

[Pavel Sanda]

On Sat, Jan 05, 2019 at 07:58:59PM -0300, Elias M. Mariani wrote:
> (maybe you want to update https://www.lyx.org/Download).

We rely on https://repology.org/metapackage/lyx/versions
for the correct version number, so that's place where
to complain. At most we can delete openbsd tag completely
if you prefer...

Pavel

Re: define LYX_USE_LONG_LONG

[Jean-Marc Lasgouttes]

Le 05/01/2019 à 23:58, Elias M. Mariani a écrit :


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.


Hello,

I would be interested to know what compiler errors you get. I'd rather 
get rid of the long long things, than tweak the again.



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


Well, that means that we do it unconditionally, right? When could the 
size be smaller?


I am not sure why we added this extra test, I'll have to dive through 
the archives.



Thanks for Lyx, I personally use it all the time and I love it.


You are welcome, and thanks for maintaining the port, we rely on people 
like you.


JMarc

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 14:03:37 CET schrieb Scott Kostyshak 
:
> On Sun, Jan 06, 2019 at 07:46:03PM +0100, Jürgen Spitzmüller wrote:
> > Am Sonntag, den 06.01.2019, 13:39 -0500 schrieb Scott Kostyshak:
> > > Nice! Thanks for implementing that, Jürgen. It would be great for it
> > > to
> > > compile with pdfTeX out of the box. I get the same error as
> > > Kornel.  I
> > > will search for more information on the map file and how to enable
> > > it.
> > 
> > Does it work for you if you insert "mj" into Document > Settings >
> > Fonts > CJK?
> > 
> > This seems to be the recommended font.
> 
> Yes, that works well. With that change, the test output looks good.
> 
> Scott

Works here too.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 14:03 -0500 schrieb Scott Kostyshak:
> Yes, that works well. With that change, the test output looks good.

Good. Would you commit this change, please?

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Scott Kostyshak]

On Sun, Jan 06, 2019 at 07:46:03PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 06.01.2019, 13:39 -0500 schrieb Scott Kostyshak:
> > Nice! Thanks for implementing that, Jürgen. It would be great for it
> > to
> > compile with pdfTeX out of the box. I get the same error as
> > Kornel.  I
> > will search for more information on the map file and how to enable
> > it.
> 
> Does it work for you if you insert "mj" into Document > Settings >
> Fonts > CJK?
> 
> This seems to be the recommended font.

Yes, that works well. With that change, the test output looks good.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 13:39 -0500 schrieb Scott Kostyshak:
> Nice! Thanks for implementing that, Jürgen. It would be great for it
> to
> compile with pdfTeX out of the box. I get the same error as
> Kornel.  I
> will search for more information on the map file and how to enable
> it.

Does it work for you if you insert "mj" into Document > Settings >
Fonts > CJK?

This seems to be the recommended font.

Jürgen

> 
> Scott


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Scott Kostyshak]

On Sun, Jan 06, 2019 at 07:14:49PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 06.01.2019, 18:08 +0100 schrieb Kornel Benko:
> > For pdflatex, I get
> > !pdfTeX error: pdflatex (file cyberbb5): Font cyberbb5 at 600
> > not found
> > 
> > I have cyberbb5.tfm installed
> > /usr/local/texlive/2018/texmf-
> > dist/fonts/tfm/zhmetrics/cyberb/cyberbb5.tfm
> > but apparently this is not enough.
> > $ kpsewhich -all cyberbb5.tfm
> 
> Looks like you don't have the map file enabled.

Nice! Thanks for implementing that, Jürgen. It would be great for it to
compile with pdfTeX out of the box. I get the same error as Kornel.  I
will search for more information on the map file and how to enable it.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 18:08 +0100 schrieb Kornel Benko:
> For pdflatex, I get
> !pdfTeX error: pdflatex (file cyberbb5): Font cyberbb5 at 600
> not found
> 
> I have cyberbb5.tfm installed
> /usr/local/texlive/2018/texmf-
> dist/fonts/tfm/zhmetrics/cyberb/cyberbb5.tfm
> but apparently this is not enough.
> $ kpsewhich -all cyberbb5.tfm

Looks like you don't have the map file enabled.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X

[Richard Kimberly Heck]

On 1/6/19 7:49 AM, Stephan Witt wrote:
> Am 06.01.2019 um 09:57 schrieb Enrico Forestieri :
>> On Sun, Jan 06, 2019 at 12:29:40AM +0100, Stephan Witt wrote:
>>> I did it with the wrapper script approach and pushed it with commit
>>> caa1dd2aee.
>> Strangely enough, your commit didn't show up on the lyx-cvs list.
> Yes, I’ve noticed that and have no idea what happened :(
>
> Riki, I’d like this change to back port to 2.3.x. This will solve the
> problem reported by Prof. Robert Betz.
>
> https://www.lyx.org/trac/changeset/caa1dd2aeed97330e05c0e96ae7e5bb929b0866d/lyxgit

OK!

Riki

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 17:18:14 CET schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 06.01.2019, 17:08 +0100 schrieb Kornel Benko:
> > > > Also the tests
> > > > INVERTED.TODO_export/examples/ko/splash_pdf2
> > > > INVERTED.TODO_export/examples/ko/splash_pdf
> > > > INVERTED.TODO_export/examples/ko/splash_pdf3
> > > > which should now fail, passes.
> > > 
> > > I don't understand this sentence.
> > > 
> > 
> > If a INVERTED test passes, it means that the real test fails.
> 
> So in plain language this means that the Korean Splash does not compile
> with pdflatex, ps2pdf and dvipdfm, right?

Yes.

> I cannot reproduce this. It compiles fine in all these formats for me.

For pdflatex, I get
!pdfTeX error: pdflatex (file cyberbb5): Font cyberbb5 at 600 not found

I have cyberbb5.tfm installed

/usr/local/texlive/2018/texmf-dist/fonts/tfm/zhmetrics/cyberb/cyberbb5.tfm
but apparently this is not enough.
$ kpsewhich -all cyberbb5.tfm
finds it.

> Jürgen

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 17:08 +0100 schrieb Kornel Benko:
> > > Also the tests
> > > INVERTED.TODO_export/examples/ko/splash_pdf2
> > > INVERTED.TODO_export/examples/ko/splash_pdf
> > > INVERTED.TODO_export/examples/ko/splash_pdf3
> > > which should now fail, passes.
> > 
> > I don't understand this sentence.
> > 
> 
> If a INVERTED test passes, it means that the real test fails.

So in plain language this means that the Korean Splash does not compile
with pdflatex, ps2pdf and dvipdfm, right?

I cannot reproduce this. It compiles fine in all these formats for me.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 16:41:15 CET schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 06.01.2019, 16:22 +0100 schrieb Kornel Benko:
> > For instance the test
> > export/examples/ko/splash_pdf4_systemF
> > passed previously, now it does not.
> 
> Should be fixed.
> 
> > Also the tests
> > INVERTED.TODO_export/examples/ko/splash_pdf2
> > INVERTED.TODO_export/examples/ko/splash_pdf
> > INVERTED.TODO_export/examples/ko/splash_pdf3
> > which should now fail, passes.
> 
> I don't understand this sentence.
> 

If a INVERTED test passes, it means that the real test fails.

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 16:22 +0100 schrieb Kornel Benko:
> For instance the test
> export/examples/ko/splash_pdf4_systemF
> passed previously, now it does not.

Should be fixed.

> Also the tests
> INVERTED.TODO_export/examples/ko/splash_pdf2
> INVERTED.TODO_export/examples/ko/splash_pdf
> INVERTED.TODO_export/examples/ko/splash_pdf3
> which should now fail, passes.

I don't understand this sentence.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 15:23:06 CET schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 06.01.2019, 15:14 +0100 schrieb Kornel Benko:
> > 
> > Nice. But now even more tests are failing.
> 
> If you provide me with details, I might be able to do something.
> 
> Jürgen
> 

For instance the test
export/examples/ko/splash_pdf4_systemF
passed previously, now it does not.
Also the tests
INVERTED.TODO_export/examples/ko/splash_pdf2
INVERTED.TODO_export/examples/ko/splash_pdf
INVERTED.TODO_export/examples/ko/splash_pdf3
which should now fail, passes.
...

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 15:14 +0100 schrieb Kornel Benko:
> 
> Nice. But now even more tests are failing.

If you provide me with details, I might be able to do something.

Jürgen

> 
>   Kornel
> 


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 14:37:27 CET schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 06.01.2019, 09:40 +0100 schrieb Kornel Benko:
> > Even if this compiles, the output looks ugly with default fonts.
> > 1.) Tons of 'Missing glyphs!'
> > 2.) See attached
> 
> Then we should fix the cause, not the symptoms.
> 
> The cause is that this document uses utf8 encoding, which triggers
> CJKutf8. This package, however, was implemented in an incomplete way
> (the document itself still used the traditional encodings, and CJK
> attempted to load the wrong fonts.
> 
> Fixed in master.
> 
> Jürgen

Nice. But now even more tests are failing.

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 09:40 +0100 schrieb Kornel Benko:
> Even if this compiles, the output looks ugly with default fonts.
> 1.) Tons of 'Missing glyphs!'
> 2.) See attached

Then we should fix the cause, not the symptoms.

The cause is that this document uses utf8 encoding, which triggers
CJKutf8. This package, however, was implemented in an incomplete way
(the document itself still used the traditional encodings, and CJK
attempted to load the wrong fonts.

Fixed in master.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Try to compute row height like it should be done

[Enrico Forestieri]

On Sun, Jan 06, 2019 at 02:10:26PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 06.01.2019, 13:35 +0100 schrieb Jean-Marc Lasgouttes:
> > Then, here is what I propose:
> > * apply the leading to the font
> > * add the 20% height leading
> 
> This sounds sensible to me.

Yes, this might work.

-- 
Enrico

Re: [RFC] Try to compute row height like it should be done

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 13:35 +0100 schrieb Jean-Marc Lasgouttes:
> Then, here is what I propose:
> * apply the leading to the font
> * add the 20% height leading

This sounds sensible to me.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X

[Stephan Witt]

Am 06.01.2019 um 09:57 schrieb Enrico Forestieri :
> 
> On Sun, Jan 06, 2019 at 12:29:40AM +0100, Stephan Witt wrote:
>> 
>> I did it with the wrapper script approach and pushed it with commit
>> caa1dd2aee.
> 
> Strangely enough, your commit didn't show up on the lyx-cvs list.

Yes, I’ve noticed that and have no idea what happened :(

Riki, I’d like this change to back port to 2.3.x. This will solve the
problem reported by Prof. Robert Betz.

https://www.lyx.org/trac/changeset/caa1dd2aeed97330e05c0e96ae7e5bb929b0866d/lyxgit

Stephan

> 
>> 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.
> 
> Yes, the change does not affect all other platforms.
> 
>> So, we postpone the problem - but this is ok for me.
>> 
>> Thank you for the discussion.
> 
> You're welcome.
> 
> -- 
> Enrico

Re: [RFC] Try to compute row height like it should be done

[Jean-Marc Lasgouttes]

Le 06/01/2019 à 10:14, Jürgen Spitzmüller a écrit :

Who says we want single-spacing? I just say that if we use, say, 1.2,
we should add yGap _on top_ of that.

MinionPro in 1.2 line spacing needs more leading than Garamond in 1.2
line spacing.


and even avoid changing the spacing if two different fonts with
different
leading suggestions are used on the same line.


I think it will be easy to just use one, then (the largest).


I mean, if the previous line contains only one font and the following
one two fonts, one of which has a larger leading, the spacing between
these two lines will be unnecessarily larger (if LyXGap > LineGap).


Then we use always the leading of the base font.


Thanks to both of you for the discussion. This is typically the 
information I was looking for.


A few data points first:
* the existing code adds a leading, which is hardcoded to 2 pixels:
// This is nicer with box insets
++maxasc;
++maxdes;
  This means that HiDPI does not get a nice leading, but for 100dpi,
  this is mostly 1.2 multiplier.
* LaTeX does use something like a 1.2 multiplier, like
\@setfontsize\normalsize\@xpt\@xiipt
  (first number 10 is font size, second number is interline)
* double spacing or such is on top of that. It is not replacing 1.2 by 2.

Then, here is what I propose:
* apply the leading to the font
* add the 20% height leading

Concerning the extra space for insets, currently the leading is added 
_inside_ the inset frame, so that the text interline regularity is 
broken by the inset presence. A good long term solution would be to 
track the leading separately (and split it evenly between top/bottom), 
so that the inset borders could live in this area. This is what is done 
in mathed already, where the edit frames are put in inter-symbol space 
if this space exists.


JMarc

Re: [RFC] Try to compute row height like it should be done

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 11:11 +0100 schrieb Enrico Forestieri:
> So, even in the current implementation the line spacing is not
> sufficient
> and needs to be incresead. Ok, understood.

Yes. With specific fonts, that is.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Try to compute row height like it should be done

[Enrico Forestieri]

On Sun, Jan 06, 2019 at 10:54:51AM +0100, Enrico Forestieri wrote:
> 
> If we add a spacing which is already larger than the suggested
> leading, what is the point of still taking into account it?

I think you already answered this previously, but I overlooked it. Sorry.

You said:
> The initial observation that lead JMarc to consider leading() was that
> some for fonts (particularly MinionPro) the leading was too close in
> (current) LyX, while for others it was OK.

So, even in the current implementation the line spacing is not sufficient
and needs to be incresead. Ok, understood.

-- 
Enrico

Re: [RFC] Try to compute row height like it should be done

[Enrico Forestieri]

On Sun, Jan 06, 2019 at 10:14:28AM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 06.01.2019, 09:49 +0100 schrieb Enrico Forestieri:
> > > My understanding is that the yGap value (Qt's leading()) accounts
> > > for
> > > the fact that different fonts need different line spacings. See
> > > https://docs.microsoft.com/en-us/typography/opentype/spec/vhea
> > > (vertTypoLineGap)
> > 
> > Yes, that is to account for accents or other typographic signs.
> 
> No. It has to do with readability. Fonts with lower ascender need more
> leading, for instance. Quoting Bringhurst:

Ok, Ok. Whatever. That is not the point ;)

> > > (This spec also confirms my observation: Height + LineGap is the
> > > recommendation for the _single_-space value of a font.)
> > 
> > Please, consider that LyX is not a typical word processing program.
> > Given the presence of inserts (something you don't find elsewhere)
> > single-spacing is not possible. We have to use a larger spacing.
> > Thus, if we use Height + LyXGap, with LyXGap > LineGap, we can
> > simply ignore LineGap.
> 
> Who says we want single-spacing? I just say that if we use, say, 1.2,
> we should add yGap _on top_ of that.
> 
> MinionPro in 1.2 line spacing needs more leading than Garamond in 1.2
> line spacing.

If we add a spacing which is already larger than the suggested
leading, what is the point of still taking into account it?

Anyway, I think that the spacing currently used by LyX is satisfactory.
I don't know whether it is 1.2 or larger, but anything less will not be
satsfactory, IMO.

-- 
Enrico

Re: [RFC] Try to compute row height like it should be done

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 09:49 +0100 schrieb Enrico Forestieri:
> > My understanding is that the yGap value (Qt's leading()) accounts
> > for
> > the fact that different fonts need different line spacings. See
> > https://docs.microsoft.com/en-us/typography/opentype/spec/vhea
> > (vertTypoLineGap)
> 
> Yes, that is to account for accents or other typographic signs.

No. It has to do with readability. Fonts with lower ascender need more
leading, for instance. Quoting Bringhurst:

"Large-bodied faces need more lead than light ones. Faces like Bauer
Bodoni, with substantial color and rigid vertical axis, need much more
lead than faces like Bembo, whose color is light and whose axis is
based on the writing hand. And unserifed faces often need more lad (or
a shorter line) than their serief counterparts." In short: "Choose a
basic leading that suits the typeface, text and measure" (p. 36-37)

The yLineGap value gives an orientation for that, based on the specific
font.

> > (This spec also confirms my observation: Height + LineGap is the
> > recommendation for the _single_-space value of a font.)
> 
> Please, consider that LyX is not a typical word processing program.
> Given the presence of inserts (something you don't find elsewhere)
> single-spacing is not possible. We have to use a larger spacing.
> Thus, if we use Height + LyXGap, with LyXGap > LineGap, we can
> simply ignore LineGap.

Who says we want single-spacing? I just say that if we use, say, 1.2,
we should add yGap _on top_ of that.

MinionPro in 1.2 line spacing needs more leading than Garamond in 1.2
line spacing.

> > > and even avoid changing the spacing if two different fonts with
> > > different
> > > leading suggestions are used on the same line.
> > 
> > I think it will be easy to just use one, then (the largest).
> 
> I mean, if the previous line contains only one font and the following
> one two fonts, one of which has a larger leading, the spacing between
> these two lines will be unnecessarily larger (if LyXGap > LineGap).

Then we use always the leading of the base font.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X

[Enrico Forestieri]

On Sun, Jan 06, 2019 at 12:29:40AM +0100, Stephan Witt wrote:
> 
> I did it with the wrapper script approach and pushed it with commit
> caa1dd2aee.

Strangely enough, your commit didn't show up on the lyx-cvs list.

> 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.

Yes, the change does not affect all other platforms.

> So, we postpone the problem - but this is ok for me.
> 
> Thank you for the discussion.

You're welcome.

-- 
Enrico

Re: [RFC] Try to compute row height like it should be done

[Enrico Forestieri]

On Sun, Jan 06, 2019 at 09:33:03AM +0100, Jürgen Spitzmüller wrote:
> Am Samstag, den 05.01.2019, 18:36 +0100 schrieb Enrico Forestieri:
> > 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
> 
> My understanding is that the yGap value (Qt's leading()) accounts for
> the fact that different fonts need different line spacings. See
> https://docs.microsoft.com/en-us/typography/opentype/spec/vhea
> (vertTypoLineGap)

Yes, that is to account for accents or other typographic signs.

> (This spec also confirms my observation: Height + LineGap is the
> recommendation for the _single_-space value of a font.)

Please, consider that LyX is not a typical word processing program.
Given the presence of inserts (something you don't find elsewhere)
single-spacing is not possible. We have to use a larger spacing.
Thus, if we use Height + LyXGap, with LyXGap > LineGap, we can
simply ignore LineGap.

> > and even avoid changing the spacing if two different fonts with
> > different
> > leading suggestions are used on the same line.
> 
> I think it will be easy to just use one, then (the largest).

I mean, if the previous line contains only one font and the following
one two fonts, one of which has a larger leading, the spacing between
these two lines will be unnecessarily larger (if LyXGap > LineGap).

-- 
Enrico

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Kornel Benko]

Am Sonntag, 6. Januar 2019 09:25:41 CET schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 06.01.2019, 01:47 -0500 schrieb Scott Kostyshak:
> > +1 I'm fine with that since the current splash is not compilable at
> > all by
> > default and since nanumGothic is a free font.
> 
> But should we really require a font that users need to install first
> for such a basic file than Splash (the first they see when they start
> LyX)?
> 
> What is the error message anyway?
> 
> Jürgen
> 
> > 
> > Scott
> 

Even if this compiles, the output looks ugly with default fonts.
1.) Tons of 'Missing glyphs!'
2.) See attached

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [RFC] Try to compute row height like it should be done

[Jürgen Spitzmüller]

Am Samstag, den 05.01.2019, 18:36 +0100 schrieb Enrico Forestieri:
> 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

My understanding is that the yGap value (Qt's leading()) accounts for
the fact that different fonts need different line spacings. See
https://docs.microsoft.com/en-us/typography/opentype/spec/vhea
(vertTypoLineGap)

(This spec also confirms my observation: Height + LineGap is the
recommendation for the _single_-space value of a font.)

BTW JMarc, not that some fonts intentionally return -1, which is
"treated as zero in some legacy platform implementations" (
https://docs.microsoft.com/en-us/typography/opentype/spec/hhea)

The initial observation that lead JMarc to consider leading() was that
some for fonts (particularly MinionPro) the leading was too close in
(current) LyX, while for others it was OK.

So I think we account for that.

> and even avoid changing the spacing if two different fonts with
> different
> leading suggestions are used on the same line.

I think it will be easy to just use one, then (the largest).

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] ctests: invert ko splash lyx22x and lyx23x tests

[Jürgen Spitzmüller]

Am Sonntag, den 06.01.2019, 01:47 -0500 schrieb Scott Kostyshak:
> +1 I'm fine with that since the current splash is not compilable at
> all by
> default and since nanumGothic is a free font.

But should we really require a font that users need to install first
for such a basic file than Splash (the first they see when they start
LyX)?

What is the error message anyway?

Jürgen

> 
> Scott


signature.asc
Description: This is a digitally signed message part