Re: [LyX/master] Revert "Fix bug #10263"
On Fri, May 28, 2021 at 10:48:51AM -0400, Scott Kostyshak wrote:
> On Tue, Apr 13, 2021 at 10:13:16AM +0200, Jean-Marc Lasgouttes wrote:
> > commit 441c6a93590698c3c57982c8b80179d6809fb106
> > Author: Jean-Marc Lasgouttes
> > Date: Mon Apr 12 20:44:58 2021 +0200
> >
> > Revert "Fix bug #10263"
> >
> > A series of commits, culminating at 812ff7de, pushed a few days later,
> > fixes the bug at its root. This one is not needed anymore to fix
> >
> > This reverts commit 001f5a47861f04c985323677dfd17ef15b8c33a7
> > ---
> > src/insets/InsetFoot.h |4
> > 1 files changed, 0 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/insets/InsetFoot.h b/src/insets/InsetFoot.h
> > index 1e4b0d2..0c3f65a 100644
> > --- a/src/insets/InsetFoot.h
> > +++ b/src/insets/InsetFoot.h
> > @@ -45,10 +45,6 @@ private:
> > ///
> > Inset * clone() const override { return new InsetFoot(*this); }
> > ///
> > - bool inheritFont() const override { return true; }
> > - ///
> > - bool allowMultiPar() const override { return true; }
> > - ///
> > docstring custom_label_;
> > ///
> > bool intitle_;
> > --
>
> The following ctest started failing with this commit:
>
> export/doc/ja/Tutorial_pdf5_systemF
>
> The diff between the "bad" (current master) and "good" (current master
> with this commit reverted) is as follows:
>
> $ diff good.tex bad.tex
> 61c61
> < \author{\LyX プロジェクトチーム\thanks{なにかコメントや間違いの修正がある場合には，\protect\LyX
> 文書化メーリングリスト(\protect\href{mailto:lyx-d...@lists.lyx.org}{lyx-d...@lists.lyx.org})までお知らせ下さい．この文書の翻訳は，当初人見光太郎氏が行った貢献に基づいています．}}
> ---
> > \author{\LyX プロジェクトチーム\thanks{{\normalsize
> > なにかコメントや間違いの修正がある場合には，\protect\LyX
> > 文書化メーリングリスト(\protect\href{mailto:lyx-d...@lists.lyx.org}{lyx-d...@lists.lyx.org})までお知らせ下さい．この文書の翻訳は，当初人見光太郎氏が行った貢献に基づいています．}}}
> $
>
> I have no idea why the {\normalsize ...} would cause the failure. Does
> anyone know the problem?
>
> Note that we are already aware of several other Japanese documents that
> do not compile with non-TeX fonts:
>
> export/doc/ja/(Additional|LaTeXConfig|Math|UserGuide).*_systemF
>
> so it would not be surprising if we need to add Tutorial.lyx to the list.
>
> By the way, if this report does not lead to a fix in LyX or a bug
> report, we should log this wasted time in
> development/autotests/ctests-costs-benefits.txt.
I think the French Powerdot example might also have a footnote where
this commit changes behavior. If I remove the footnote, compilation
succeeds. I did not do a bisect on that document but it feels like a
similar issue.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Anyone on TeX Live 2021 pretest ? (to confirm a regression for ja LilyPond)
On Sun, May 23, 2021 at 10:24:15AM +0200, Kornel Benko wrote: > Am Sat, 22 May 2021 21:43:18 -0400 > schrieb Scott Kostyshak : > > > On Sat, May 22, 2021 at 05:26:10PM +0200, Kornel Benko wrote: > > > Am Sat, 22 May 2021 16:51:43 +0200 > > > schrieb Jürgen Spitzmüller : > > > > > > > Am Samstag, dem 22.05.2021 um 16:33 +0200 schrieb Kornel Benko: > > > > > Fine. But how to explain that running with 2020-dvipdfmx compiles on > > > > > TL20, but the same dvipdfmx (copied from TL20) fails if using TL20 > > > > > env. > > > > > > > > Stricter security measures have been introduced with TL 21 [1]. > > > > > > > > The produced DVI is fine, but dvipdfmx does not produce a PDF due to > > > > access restrictions (when attempting to access fonts). > > > > > > > > When processing the DVI with > > > > > > > > dvipdfmx -i dvipdfmx-unsafe.cfg > > > > > > > > it works, i.e., after changing the converter DVI > PDF (dvipdfm) to > > > > dvipdfmx -i dvipdfmx-unsafe.cfg -o $$o $$i > > > > > > > > dvipdfmx-unsafe.cfg makes dvipdfmx call gs (rungs) with -dNOSAFER > > > > rather than with -DSAFER (as in the default dvipdfmx.cfg of TL21). > > > > > > Thanks. > > > > > > > However, this change should definitely only be applied to trustworthy > > > > files, so changing the converter generally is certainly not such a good > > > > idea. > > > > > > > > Jürgen > > > > > > > > [1] The explicit call of -DSAFER has been introduced for TL 21: > > > > https://tug.org/pipermail/tex-live-commits/2021-March/017216.html > > > > > > > > > > That means that we could use this setting for our tests. > > > > Thanks for following up on this, Kornel. I think I stopped looking into > > this issue because I thought it was due to a known bug with a fix in > > progress. > > > > Scott > > Committed change to prefTest.pm to add "-i dvipdfmx-unsafe.cfg" as > parameter for dvipdfmx in our test environment. > > To use: > $ cd > $ ./prefTest.pl test I think there is a related issue: Some exports that use ps2pdf now seem to need the flag "-dALLOWPSTRANSPARENCY" on TL21. Adding the following line to my preferences file fixes some tests: \converter "ps" "pdf" "ps2pdf -dALLOWPSTRANSPARENCY $$i $$o" "hyperref-driver=dvips I believe that this fixes the failures in the following tests: export/examples/Presentations/Powerdot_lyx22 (Failed) export/examples/Presentations/Powerdot_lyx23 (Failed) DEFAULTOUTPUT_export/examples/Presentations/Powerdot_pdf (Failed) export/examples/Articles/Chess/Game_2_lyx22 (Failed) export/examples/Articles/Chess/Game_2_lyx23 (Failed) DEFAULTOUTPUT_export/examples/Articles/Chess/Game_2_pdf (Failed) export/examples/Graphics_and_Insets/Instant_Preview_lyx22 (Failed) export/examples/Graphics_and_Insets/Instant_Preview_lyx23 (Failed) DEFAULTOUTPUT_export/examples/Graphics_and_Insets/Instant_Preview_pdf (Failed) Interestingly, the flag fixes the English Powerdot tests but not the French ones. I think the failures in the French document might be additionally related to 441c6a93. I've started some discussion on that commit. I took a look at sub getConverter($$) but I'm not sure my Perl skills are good enough to create a non-hackish patch. Kornel, are you interested? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Qt6 sets UNICODE on Windows
Am Sa., 29. Mai 2021 um 18:43 Uhr schrieb Yu Jin : > Am Sa., 29. Mai 2021 um 10:57 Uhr schrieb Yu Jin : > >> >> >> Am Sa., 29. Mai 2021 um 10:22 Uhr schrieb Kornel Benko : >> >>> Am Sat, 29 May 2021 09:56:06 +0200 >>> schrieb Yu Jin : >>> >>> > this is connected to the Beta 1 tarballs, trying to build LyX I >>> stumbled >>> > across this: >>> > [image: grafik.png] >>> > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when >>> > configuring without LYX_CONSOLE. It does that by setting the character >>> set >>> > to Unicode (as shown in the screenshot above) and it also sets the >>> > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does >>> not do >>> > that. I have just tried to manually change the character set and remove >>> > those definitions in Visual Studio and it worked just fine. Any Idea if >>> > this is intended by us or how we can prevent it? Maybe in CMake? >>> >>> The only setting for UNICODE i see is in >>> development/Win32/vld/cmake/CMakeLists.txt >>> This is used, if LYX_VLD is set. But this should be OFF on default. >>> >> >> Thank you for your response. Actually it is Qt6 after all, I just tested >> on a minimal example, it seems that Windows GUI applications are indeed >> defaulted to UNICODE on Qt6. I also just found in the keynote here: >> https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf >> >> QtCore classes can now only deal with Unicode encodings >> –For other encodings: QTextCodec in Qt5Compat >> >> Don't really understand what that really means for LyX. But Qt5Compat is >> used, so I hope it will be fine. I will ask in the Qt Forum how the UNICODE >> default can be deactivated. >> > > There was a bug report already: > https://bugreports.qt.io/browse/QTBUG-89951 > apparently the unicode default will stay for all WIN32 (Windows GUI) > applications and it will be possible to disable only with the next (6.1.1) > release. > > But I also think that the "universal" function calls (CreateNamedPipe() > and WaitNamedPipe()) should be made specific (CreateNamedPipeA() and > WaitNamedPipeA()), because the arguments are also specific (c_str() always > returns const char*). I have attached the patch showing it, the patch alone > fixes the compilation with unicode definition (can I commit it?). Once Qt > 6.1.1 releases though, I will create a patch to disable unicode in CMake > again. > Forgot the patch. -- Eugene file.diff Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Qt6 sets UNICODE on Windows
Am Sa., 29. Mai 2021 um 10:57 Uhr schrieb Yu Jin : > > > Am Sa., 29. Mai 2021 um 10:22 Uhr schrieb Kornel Benko : > >> Am Sat, 29 May 2021 09:56:06 +0200 >> schrieb Yu Jin : >> >> > this is connected to the Beta 1 tarballs, trying to build LyX I stumbled >> > across this: >> > [image: grafik.png] >> > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when >> > configuring without LYX_CONSOLE. It does that by setting the character >> set >> > to Unicode (as shown in the screenshot above) and it also sets the >> > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does >> not do >> > that. I have just tried to manually change the character set and remove >> > those definitions in Visual Studio and it worked just fine. Any Idea if >> > this is intended by us or how we can prevent it? Maybe in CMake? >> >> The only setting for UNICODE i see is in >> development/Win32/vld/cmake/CMakeLists.txt >> This is used, if LYX_VLD is set. But this should be OFF on default. >> > > Thank you for your response. Actually it is Qt6 after all, I just tested > on a minimal example, it seems that Windows GUI applications are indeed > defaulted to UNICODE on Qt6. I also just found in the keynote here: > https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf > > QtCore classes can now only deal with Unicode encodings > –For other encodings: QTextCodec in Qt5Compat > > Don't really understand what that really means for LyX. But Qt5Compat is > used, so I hope it will be fine. I will ask in the Qt Forum how the UNICODE > default can be deactivated. > There was a bug report already: https://bugreports.qt.io/browse/QTBUG-89951 apparently the unicode default will stay for all WIN32 (Windows GUI) applications and it will be possible to disable only with the next (6.1.1) release. But I also think that the "universal" function calls (CreateNamedPipe() and WaitNamedPipe()) should be made specific (CreateNamedPipeA() and WaitNamedPipeA()), because the arguments are also specific (c_str() always returns const char*). I have attached the patch showing it, the patch alone fixes the compilation with unicode definition (can I commit it?). Once Qt 6.1.1 releases though, I will create a patch to disable unicode in CMake again. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Qt6 sets UNICODE on Windows
Am Sa., 29. Mai 2021 um 10:22 Uhr schrieb Kornel Benko : > Am Sat, 29 May 2021 09:56:06 +0200 > schrieb Yu Jin : > > > this is connected to the Beta 1 tarballs, trying to build LyX I stumbled > > across this: > > [image: grafik.png] > > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when > > configuring without LYX_CONSOLE. It does that by setting the character > set > > to Unicode (as shown in the screenshot above) and it also sets the > > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does not > do > > that. I have just tried to manually change the character set and remove > > those definitions in Visual Studio and it worked just fine. Any Idea if > > this is intended by us or how we can prevent it? Maybe in CMake? > > The only setting for UNICODE i see is in > development/Win32/vld/cmake/CMakeLists.txt > This is used, if LYX_VLD is set. But this should be OFF on default. > Thank you for your response. Actually it is Qt6 after all, I just tested on a minimal example, it seems that Windows GUI applications are indeed defaulted to UNICODE on Qt6. I also just found in the keynote here: https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf QtCore classes can now only deal with Unicode encodings –For other encodings: QTextCodec in Qt5Compat Don't really understand what that really means for LyX. But Qt5Compat is used, so I hope it will be fine. I will ask in the Qt Forum how the UNICODE default can be deactivated. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Qt6 sets UNICODE on Windows
Am Sat, 29 May 2021 09:56:06 +0200 schrieb Yu Jin : > this is connected to the Beta 1 tarballs, trying to build LyX I stumbled > across this: > [image: grafik.png] > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when > configuring without LYX_CONSOLE. It does that by setting the character set > to Unicode (as shown in the screenshot above) and it also sets the > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does not do > that. I have just tried to manually change the character set and remove > those definitions in Visual Studio and it worked just fine. Any Idea if > this is intended by us or how we can prevent it? Maybe in CMake? The only setting for UNICODE i see is in development/Win32/vld/cmake/CMakeLists.txt This is used, if LYX_VLD is set. But this should be OFF on default. Kornel pgp6MRTxFLgjj.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
Am Do., 27. Mai 2021 um 22:49 Uhr schrieb Yu Jin : > Am Do., 27. Mai 2021 um 20:17 Uhr schrieb Yu Jin : > >> Am Mo., 24. Mai 2021 um 21:18 Uhr schrieb Richard Kimberly Heck < >> rikih...@lyx.org>: >> >>> Hi, all, >>> >>> I have put tarballs for beta 1 here: >>> >>> >>> https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing >>> >>> I need to get my IP updated with our FTP people before I can upload >>> again to ftp.lyx.org. Usually that does not take too long. In any >>> event, >>> please prepare binaries, and I'll release later this week. >>> >> >> Unfortunately these don't compile for me, I get these errors: >> >> Severity Code Description Project File Line Suppression State >> Error C2664 'BOOL WaitNamedPipeW(LPCWSTR,DWORD)': cannot convert argument >> 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX) >> C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 530 >> Error C2664 'HANDLE >> CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': >> cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX >> (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 178 >> Error C2664 'HANDLE >> CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': >> cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX >> (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 492 >> >> Only occurs when LYX_CONSOLE is disabled though, which is what we want >> for the beta release. >> > Ah, I see, it's because of the > > UNICODE > _UNICODE > > preprocessor definitions What to do about that then? > I removed those for these tarballs (see also the other thread which I just started) and successfully built LyX, so Uploaded the installer as usual (only 64 bit, as mentioned earlier). I guess this is a good time to see how Qt6 goes, since it is a beta. If people ask for 32 bit, I can still build it later. Hopefully the UNICODE thing gets resolved until the next release/beta. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Qt6 sets UNICODE on Windows
this is connected to the Beta 1 tarballs, trying to build LyX I stumbled across this: [image: grafik.png] Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when configuring without LYX_CONSOLE. It does that by setting the character set to Unicode (as shown in the screenshot above) and it also sets the "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does not do that. I have just tried to manually change the character set and remove those definitions in Visual Studio and it worked just fine. Any Idea if this is intended by us or how we can prevent it? Maybe in CMake? -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
