Re: How to setup image converters on Mac?
Am 30.09.2017 um 20:15 schrieb Scott Kostyshak : > > On Wed, Sep 20, 2017 at 09:11:53PM +, Scott Kostyshak wrote: > >>> But this is too complex for 2.3.0, IMO. So I’d put my patch in and >>> let some nice guys change the splash files. > > From what I understand, after your most recent patch is put in 2.3.x, we > no longer need a patch for the splash files. Is that correct? Yes, it’s correct. I need to put it into 2.3.x after it’s in master. I’m not sure if I need some feedback it doesn’t break the build on other platforms. The Cmake build I've not extended too. Stephan
Uninvert tests fixed by #8823 fix
The inverted Japanese knitr/sweave/lilypond tests are failing (meaning the exports pass), except for the lilypond export that goes through ps2pdf. For that I get an error from ps2pdf: Error: /invalidfileaccess in --file-- Günter, Kornel, if you have time (no problem if more important things to worry about), on current 2.3.x do you also see the failures of the inverted tests, and do you also see the ps2pdf error I mention above? If you do see the ps2pdf error, do you have a guess of where the root problem is? e.g. our export, or Lilypond's creation or dvips or ps2pdf? Attached is a patch. Scott From 9f0173f8bcd77817f3190aef407cfca305924295 Mon Sep 17 00:00:00 2001 From: Scott Kostyshak Date: Sat, 30 Sep 2017 22:52:57 -0400 Subject: [PATCH] Uninvert Japanese tests after fix to #8823 The export ja/lilypond_pdf failes because ps2pdf gives an error. It is thus still inverted, under the category 'externalissues'. --- development/autotests/invertedTests | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/development/autotests/invertedTests b/development/autotests/invertedTests index f8494be..c44b1ac 100644 --- a/development/autotests/invertedTests +++ b/development/autotests/invertedTests @@ -126,9 +126,6 @@ Sublabel: lyxbugs # LyX bugs with a Trac number. # -#8823 documents requiring pre-processing fail with Japanese -export/examples/ja/(knitr|lilypond|sweave)_(dvi|pdf3?) - #10355 xmllint detects failures export/doc/attic/eu_UserGuide_xhtml export/doc/(es|ja)/UserGuide_xhtml @@ -266,6 +263,18 @@ export/templates/es_beamer-conference-ornate-20min_pdf4_texF check_load/templates/acmart +# +Sublabel: externalissues +# Export fails due to non-LaTeX external tool, +# +# +# e.g. a bug or missing feature in ps2pdf + +# ps2pdf gives the following and exits with error: +# Error: /invalidfileaccess in --file-- +export/examples/ja/lilypond_pdf + + # == Sublabel: attic # Documents in the attic, kept for reference and format conversion test. -- 2.7.4 signature.asc Description: PGP signature
Can you view the Japanese PDFs created with PDF (ps2pdf) ?
If you compile e.g. the Japanese splash to PDF (ps2pdf), does the PDF output look good to you? For me, both PDF (ps2pdf) and PDF (dvipdfm) export with success, but on the PDF created with ps2pdf I see jibberish instead of Japanese characters. Scott signature.asc Description: PGP signature
Re: [LyX/master] Reset default output format to default for Japanese docs.
On Sat, Sep 09, 2017 at 07:05:48AM +, Juergen Spitzmueller wrote: > commit 27165841154b0b667cea96ef6862a1117baa2e86 > Author: Juergen Spitzmueller > Date: Sat Sep 9 09:03:57 2017 +0200 > > Reset default output format to default for Japanese docs. > > Since we have a global default now, these local settings are not > necessary anymore. > --- > lib/doc/ja/Additional.lyx|2 +- > lib/doc/ja/Customization.lyx |2 +- > lib/doc/ja/EmbeddedObjects.lyx |2 +- > lib/doc/ja/Formula-numbering.lyx |2 +- > lib/doc/ja/Intro.lyx |2 +- > lib/doc/ja/LaTeXConfig.lyx |2 +- > lib/doc/ja/Math.lyx |2 +- > lib/doc/ja/Shortcuts.lyx |2 +- > lib/doc/ja/Tutorial.lyx |2 +- > lib/doc/ja/UserGuide.lyx |2 +- Can we make this change also for the ja examples and also for DummyDocument1.lyx and DummyDocument2.lyx ? I volunteer to do it, I just wanted to check if there is a reason not to. Scott signature.asc Description: PGP signature
Re: fix lyx2lyx dash conversion (patch attached)
On Sat, Sep 30, 2017 at 10:12:28PM +, Guenter Milde wrote: > The patch allows removal of all dash-related caveats in the 2.3 RELEASE NOTES. > > Please try it out and give a +1 or improvement suggestions. (to any potential patch reviewers) In case anyone is concerned about a regression, let me know if there is any result from our export ctests that would be useful in deciding to give a +1 to the patch. I would be happy to run our extensive set of tests using this patch. I could, for example, run the tests on the 2.2.x branch of the LyX documents, or from 2.1.x versions. Just let me know specifically what you would like me to test. I could compare results with/without the patch. Scott signature.asc Description: PGP signature
fix lyx2lyx dash conversion (patch attached)
Dear LyX developers,
the attached patch cleans up lyx2lyx issues after the recent fixes to
dash handling in LyX. Commiting requires the +1 from at least one other
developer.
* Backwards compatibility for both, documents containing literal dashes and
documents containing ligature dashes.
Currently, "\use_dash_ligatures" is set based on the original file version.
If you used literal em- and en-dashes in pre-2.2 documents,
you must manually unselect "Output em- and en-dash as ligatures" to
ensure unchanged behaviour.
The patch ensures content is scanned for literal and ligature dashes
and the setting set to ensure unchanged line breaks.
Pre-LyX 2.2 documents with both, literal AND ligature dashes
trigger a warning and uses the default value for "\use_dash_ligatures".
We could also consider ERT in these (rare) cases.
* Round-trip 2.3 -> -> 2.3 keeps "\use_dash_ligatures"
value.
Currently, , the original value of the setting is lost:
2.3 -> 2.2 -> 2.3 forces "\use_dash_ligatures false" and
2.3 -> 2.1 (and older) -> 2.3 forces "\use_dash_ligatures true".
* Backwards compatibility for 2.2 via preamble code.
Currently, the 2.2 workaround uses zero width space (ZWSP) characters.
Re-defining \textemdash and \textendash ensures unchanged output also
regarding hyphenation of words adjacent to the dashes. The preamble code
is removed when converting from 2.2 (both directions).
* Conversion 2.3 -> 2.1 (or older) produces ligature dashes if
"\use_dash_ligatures true".
Currently, the 2.2 workaround with literal dash + ZWSP is also used for
export to 2.1 and older with suboptimal results and problems with the
ZWSP character in 2.0 and earlier.
The patch allows removal of all dash-related caveats in the 2.3 RELEASE NOTES.
Please try it out and give a +1 or improvement suggestions.
Günter
- End forwarded message -
>From 0691a3537cbadc0336edd9f47b14e8047a39cad2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=BCnter=20Milde?=
Date: Sat, 30 Sep 2017 23:26:02 +0200
Subject: [PATCH] Fix lyx2lyx conversion of dashes.
---
lib/RELEASE-NOTES | 32 ++-
lib/lyx2lyx/lyx_2_2.py | 6 ++
lib/lyx2lyx/lyx_2_3.py | 153 -
3 files changed, 87 insertions(+), 104 deletions(-)
diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES
index 440b93e71a..007ae575ee 100644
--- a/lib/RELEASE-NOTES
+++ b/lib/RELEASE-NOTES
@@ -13,13 +13,12 @@
be safely dissolved, as it will be automatically inserted at export time
if needed, as usual.
-* The new setting
- "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces
- output of en- and em-dashes as -- and --- when exporting to LaTeX.
- It is is "true" by default but "false" when opening documents edited
- with LyX 2.2.
- See chapter 3.9.1.1 "Dashes and line breaks" of the User Guide and
- "Caveats when upgrading from earlier versions to 2.3.x" below.
+* The new setting "Output em- and en-dash as ligatures" under
+ "Document->Settings->Fonts" forces output of en and em dashes as -- and
+ --- when exporting to LaTeX. The default is "true". When opening old
+ documents, the setting is "false" if literal dashes were used and
+ different line breaks might occur. See chapter 3.9.1.1 "Dashes and line
+ breaks" of the User Guide for details.
* The following UI translations were dropped, because the lack of translation
maintenance: Russian, Danish, Greek, Serbian, Galician, Catalan, Romanian,
@@ -209,25 +208,6 @@
the external_templates file, you will have to move the modifications to
the respective *.xtemplate file manually.
-* If you used literal em- and en-dashes in pre-2.2 documents,
- you must manually unselect
- "Document->Settings->Fonts->Output em- and en-dash as ligatures"
- to ensure unchanged behaviour.
-
-* ZWSP characters (u200b) following literal em- and en-dashes are deleted by
- lyx2lyx when converting to 2.3 format. If you used them as optional line
- breaks after dashes, convert them to space insets before opening your
- document with LyX 2.3 or the optional line breaks will be lost!
-
-* If using TeX fonts and en- and em-dashes are output as font ligatures,
- when exporting documents containing en- and em-dashes to the format of
- LyX 2.0 or earlier, the following line has to be manually added to the
- unicodesymbols file of that LyX version:
- 0x200b "\\hspace{0pt}" "" "" "" "" # ZERO WIDTH SPACE
- This avoids "uncodable character" issues if the document is actually
- loaded by that LyX version. LyX 2.1 and later versions already have the
- necessary definition in their unicodesymbols file.
-
* If trying to compile documents using R scripts and sweave/knitr, LyX
2.3.x would not allow for re-running the R scripts, unless the user:
1) explicitly disables the "Forbid use of needauth converters"
diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index 996c22684e..2f4ef3ac2
fix lyx2lyx dash conversion (patch)
Dear LyX developers, the attached patch cleans up lyx2lyx issues after the recent fixes to dash handling in LyX. Commiting requires the +1 from at least one other developer. * Backwards compatibility for both, documents containing literal dashes and documents containing ligature dashes. Currently, "\use_dash_ligatures" is set based on the original file version. If you used literal em- and en-dashes in pre-2.2 documents, you must manually unselect "Output em- and en-dash as ligatures" to ensure unchanged behaviour. The patch ensures content is scanned for literal and ligature dashes and the setting set to ensure unchanged line breaks. Pre-LyX 2.2 documents with both, literal AND ligature dashes trigger a warning and uses the default value for "\use_dash_ligatures". We could also consider ERT in these (rare) cases. * Round-trip 2.3 -> -> 2.3 keeps "\use_dash_ligatures" value. Currently, , the original value of the setting is lost: 2.3 -> 2.2 -> 2.3 forces "\use_dash_ligatures false" and 2.3 -> 2.1 (and older) -> 2.3 forces "\use_dash_ligatures true". * Backwards compatibility for 2.2 via preamble code. Currently, the 2.2 workaround uses zero width space (ZWSP) characters. Re-defining \textemdash and \textendash ensures unchanged output also regarding hyphenation of words adjacent to the dashes. The preamble code is removed when converting from 2.2 (both directions). * Conversion 2.3 -> 2.1 (or older) produces ligature dashes if "\use_dash_ligatures true". Currently, the 2.2 workaround with literal dash + ZWSP is also used for export to 2.1 and older with suboptimal results and problems with the ZWSP character in 2.0 and earlier. The patch allows removal of all dash-related caveats in the 2.3 RELEASE NOTES. Please try it out and give a +1 or improvement suggestions. Günter
Let's go with Qt 5.6.3 for 2.3.0 rc1 and final?
Dear all, Qt 5.6.3 was released a week ago [1]. Do you agree that it makes sense to go forward with 5.6.3 for the LyX 2.3.0 rc1 and final releases for the Mac and Win binaries? Uwe, Stephan, I'm especially interested in your thoughts. I suppose the other choices would be Qt 5.9.2, or perhaps 5.6.2 if we are worried about a regression that might have been introduced in 5.6.3, since we released beta1 with 5.6.2. But since our next release will be an rc (and not final), I think we should trust the point release and go with 5.6.3 over 5.6.2. As for 5.9.2, the 5.9 release supposedly fixes "many more bugs" [1] than the 5.6.3 release. I don't know if that is partly because many bugs were introduced in 5.9.x? Both 5.6.x and 5.9.x have Long Term Support. From what I understand, Qt 5.6.x will be supported until March 2019 (3 years from the final release of 5.6.0), and 5.9.x will be supported until May 2020. If we go with Qt 5.6.x, this might mean our last point release of LyX 2.3.x will either ship with an "unsupported" 5.6.x, or we would change to a difference Qt version. I don't think we have cared too much about trying to stay on the same Qt major series throughout the LyX series releases, so I don't think it's much of an issue. The Qt 5.9.2 snapshot is available and I believe the final release will be out in a couple days. I'm not sure what to think about the following, from the recent announcement of the 5.9.2 snapshot [2]: But please note: Qt 5.9.3 will follow soon and so on we won't block Qt 5.9.2 release that easily. It means if issue were in Qt 5.9.1 we can release Qt 5.9.2 with it as well. And no any nice-to-haves in anymore; those can wait Qt 5.9.3 from now on... If there were e.g. a regression from 5.9.0 to 5.9.1, then it is not necessarily a blocker for 5.9.2? Perhaps it is just a general warning, but I can't help but think there might be some annoying bugs that are known in the 5.9.2 release. In summary, I would say that unless we know of a Qt bug that specifically affects LyX that is fixed in 5.9.2 and that is not fixed in 5.6.3, then we should go with 5.6.3 at this point. Going with 5.9.2 might lead to further delay of the LyX 2.3.0 release (because I think there's a higher chance of discovering a bug that affects LyX when going from 5.6.2 to 5.9.2 than from 5.6.2 to 5.6.3). Uwe, Stephan, would it be too much work to create binaries for both? Even if we decide to go with 5.6.3, sometimes we get reports of crashes that we cannot reproduce. It would be nice to say "can you try this binary to see if you also get the crash with 5.9.2"? Any thoughts? Scott [1] http://blog.qt.io/blog/2017/09/21/qt-5-6-3-released/ [2] http://lists.qt-project.org/pipermail/releasing/2017-September/004571.html signature.asc Description: PGP signature
Re: How to setup image converters on Mac?
On Wed, Sep 20, 2017 at 09:11:53PM +, Scott Kostyshak wrote: > > But this is too complex for 2.3.0, IMO. So I’d put my patch in and > > let some nice guys change the splash files. From what I understand, after your most recent patch is put in 2.3.x, we no longer need a patch for the splash files. Is that correct? Scott signature.asc Description: PGP signature
Re: after i change one line to other form ,the input method will be changed to english.and i can't change it by shoutcuts.
On Mon, Aug 21, 2017 at 03:19:24AM +, ly1126225520 wrote: > after i change one line to other form ,the input method will be > changed to english.and i can't change it by shoutcuts. > > os=windows Windows 10 Version 1703 > lyx version = 2.2.3 > [] Dear ly1126225520, What do you mean by "change one line to other form" ? Could you please give exact steps that I can follow to reproduce the problem? E.g. something like: 1. Set the document language to... 2. Write "hello world", then... Feel free to talk to me like I'm a 5-year-old. Often that's the best way for me to understand :) Best, Scott signature.asc Description: PGP signature
Plus 1 for non-documentation patches
Dear all, Since we are close to rc1, please only commit non-documentation patches to the 2.3.x branch if you get a +1 from another developer. I would prefer to see an explicit "+1 for 2.3.0" (or something similar) from the developer giving a +1, rather than e.g. "looks reasonable". Uwe it's up to you if you want a policy for documentation-related patches. Thanks to all for the help in moving towards rc1. Scott signature.asc Description: PGP signature
Re: Fwd: Blurry inserted figures for retina display in Lyx 2.2 Mac
On Wed, Sep 27, 2017 at 05:03:11PM +, Zhexuan Gong wrote: > Dear Scott, > > Thanks for the reply! Yes I'd be happy to test the 2.3.0rc1 to see if the > problem persists. > > Best, > > Zhexuan Dear Zhexuan, Great, thanks for being willing to test! You can subscribe to lyx-announce [1] if you want, but I made a note to myself to also send you an email directly. Thanks, Scott [1] https://www.lyx.org/MailingLists#toc4 > On Wed, Sep 27, 2017 at 12:44 PM, Scott Kostyshak wrote: > > > On Mon, Sep 25, 2017 at 06:21:20PM +, Zhexuan Gong wrote: > > > Dear Lyx developers, > > > > > > It looks like this problem is still not fixed in the latest Lyx 2.2.3 Mac > > > version. Has anyone been working on this? > > > > > > Thanks a lot! > > > > > > Zhexuan > > > > Dear Zhexuan, > > > > Thank you for your persistence! I think that part of the problem is that > > LyX developers do not all have access to retina screens. > > > > Would you be willing to test 2.3.0rc1 when it is available in a couple > > of weeks? It would be good to know if you still see the problem with > > 2.3.0rc1. > > > > Thanks, > > > > Scott > > signature.asc Description: PGP signature
Re: hyphen and dashes documentation
On Thu, Sep 28, 2017 at 08:52:54PM +, Guenter Milde wrote: > Dear Scott, dear Uwe, > > please find attached a revision of the last changes to the English and > German UserGuide chapter 3.9.1 "Hyphens, Dashes, and Minus Signs". > It corrects typos and errors and adds some information while on the same > time trims the chapter a bit. > > What is the procedure for upload? Uwe, how should Günter proceed? > I still plan to solve some of the issues instead of just documenting them, > so a second revision may follow after a patch. Sounds good. Before spending time on a patch, you might want to ask on the list to get a +1 on the plan. At this point, I would like all changes to code (e.g. not documentation) to get an explicit +1 before committing. I'll send an email to the list about this. Thanks for your work on this, Scott signature.asc Description: PGP signature
Re: [PATCH] How to setup image converters on Mac?
On Thu, Sep 28, 2017 at 07:30:45AM +, Enrico Forestieri wrote: > On Wed, Sep 27, 2017 at 10:34:20PM +0200, Stephan Witt wrote: > > > > Ok, here is my next proposed patch. Now lyxconvert should be compiled > > and installed on Mac only, in convertDefault.py a test for platform > > darwin is active to ensure it is called on Mac only. > > > > This should avoid to fix something not broken on Linux and Windows. > > > > I’ve tested on Mac with (a temporary change to) INSTALL_WINDOWS to > > ensure it works as null target on other platforms - but that’s not a > > real test. It would be nice to hear if it works on Linux, Cygwin and > > Windows as well. > > It works on Linux, Cygwin, and Windows when compiling with mingw ed autotools. Thanks for testing. Stephan, please go ahead for 2.3.x branch. Scott signature.asc Description: PGP signature
Re: LyX-Workarea: Background not shown correctly
Am 30.09.2017 um 17:58 schrieb Jean-Marc Lasgouttes : > > Le 29/09/2017 à 10:39, Jean-Marc Lasgouttes a écrit : >> I suspect I am missing something. I do not see how running view pdflatex may >> interfere? A screencast, maybe? > > Is it that the LyX window is not repainted correctly when it is covered by > another one? No, that’s not the problem. It looks like a problem with the „backing store“. After a resize the work area is shown ok. The cursor movement turns most of it into black. When the cursor reaches the bottom of the window and the contents gets scrolled it is ok again - because of the full redraw probably. Moving the cursor one line up the black screen is back. The pdflatex run is not the problem. It has the same affect as the cursor down without the cursor movement - so the whole work area is black. No redraw is required but the restore of the painted contents does not work, AFAICS. ATM, I have not enough time to make the screencast, sorry. Stephan
Re: LyX-Workarea: Background not shown correctly
Le 29/09/2017 à 10:39, Jean-Marc Lasgouttes a écrit : I suspect I am missing something. I do not see how running view pdflatex may interfere? A screencast, maybe? Is it that the LyX window is not repainted correctly when it is covered by another one? JMarc
