Re: Issues to discuss for 2.2.0rc1

2016-04-03 Thread Scott Kostyshak 
On Sat, Apr 02, 2016 at 07:15:15PM +0200, Peter Kümmel wrote:
> Am 2. April 2016 18:48:12 MESZ, schrieb Scott Kostyshak :
> >On Sat, Apr 02, 2016 at 11:11:33AM +0200, Peter Kümmel wrote:
> >> 
> >> I've found a solution for the strange crashes, strfwd.h must always
> >included first, if not the compiler makes assumption which are wrong.
> >> Now config.h for msvc2015 includes strfwd.h, not very nice but it
> >solves the issue.
> >
> >Thank you for the fix.
> >
> >> So I think we could risk a msvc2015/Qt 5.6.0 release.
> >
> >I want to make sure I understand this statement. I interpret this to
> >mean that it might not be crazy of us to do a MSVC2015/Qt 5.6.0
> >release.
> >
> >Or should I interpret it to mean that you now recommend a
> >MSVC2015/Qt 5.6.0 release over a MSVC2010/Qt 5.5.1 release?
> >
> >Scott
> 
> I recomment now the msvc2015/Qt5.6.0 build. I think the risk is minimal, sure 
> we drop the beta feedback, but I have the impression there was not much 
> feedback. And 5.6 has features which users will miss, especially on Win 10.

OK good to know.

> And when we get horror feedback from the rc1 we could still go back.
> 
> Btw, why are the betas and rcs not announced on the webpage?

I should have put the beta announcements up. I will put the rc1
announcement when it's released.

Scott


signature.asc
Description: PGP signature

Re: Issues to discuss for 2.2.0rc1

2016-04-02 Thread Peter Kümmel 
Am 2. April 2016 18:48:12 MESZ, schrieb Scott Kostyshak :
>On Sat, Apr 02, 2016 at 11:11:33AM +0200, Peter Kümmel wrote:
>> 
>> I've found a solution for the strange crashes, strfwd.h must always
>included first, if not the compiler makes assumption which are wrong.
>> Now config.h for msvc2015 includes strfwd.h, not very nice but it
>solves the issue.
>
>Thank you for the fix.
>
>> So I think we could risk a msvc2015/Qt 5.6.0 release.
>
>I want to make sure I understand this statement. I interpret this to
>mean that it might not be crazy of us to do a MSVC2015/Qt 5.6.0
>release.
>
>Or should I interpret it to mean that you now recommend a
>MSVC2015/Qt 5.6.0 release over a MSVC2010/Qt 5.5.1 release?
>
>Scott

I recomment now the msvc2015/Qt5.6.0 build. I think the risk is minimal, sure 
we drop the beta feedback, but I have the impression there was not much 
feedback. And 5.6 has features which users will miss, especially on Win 10.

And when we get horror feedback from the rc1 we could still go back.

Btw, why are the betas and rcs not announced on the webpage?

Peter

Re: Issues to discuss for 2.2.0rc1

2016-04-02 Thread Scott Kostyshak 
On Sat, Apr 02, 2016 at 11:11:33AM +0200, Peter Kümmel wrote:
> 
> I've found a solution for the strange crashes, strfwd.h must always included 
> first, if not the compiler makes assumption which are wrong.
> Now config.h for msvc2015 includes strfwd.h, not very nice but it solves the 
> issue.

Thank you for the fix.

> So I think we could risk a msvc2015/Qt 5.6.0 release.

I want to make sure I understand this statement. I interpret this to
mean that it might not be crazy of us to do a MSVC2015/Qt 5.6.0 release.

Or should I interpret it to mean that you now recommend a
MSVC2015/Qt 5.6.0 release over a MSVC2010/Qt 5.5.1 release?

Scott


signature.asc
Description: PGP signature

Re: Issues to discuss for 2.2.0rc1

2016-04-02 Thread Peter Kümmel 



Am 27.03.2016 um 21:38 schrieb Uwe Stöhr:

Am 20.03.2016 um 21:48 schrieb Scott Kostyshak:


Peter stated [1] that the patch is not necessary for compilation with
MSVC 2010.


But it doesn't harm then, see my today's post in the plans thread.


It seems the majority opinion is to release rc1 (and final
2.2.0) with Qt 5.5.1 compiled with MSVC 2010. Uwe, are you OK with that?


As I just wrote in the other thread I prefer Qt 5.6.
I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6 version. 
However, for the final release I won't maintain/offer support for a Qt 5.5.1 
build. Due to lack of time I will have to focus on one version and Qt 5.6 
offers a long term support, meaning I can assume that this version will be 
supported by the Qt people for the full life time of LyX 2.2.

I hope you can understand my decision.

regards Uwe



I've found a solution for the strange crashes, strfwd.h must always included 
first, if not the compiler makes assumption which are wrong.
Now config.h for msvc2015 includes strfwd.h, not very nice but it solves the 
issue.

So I think we could risk a msvc2015/Qt 5.6.0 release.

Peter

Re: Issues to discuss for 2.2.0rc1

2016-04-02 Thread Kornel Benko 
Am Freitag, 1. April 2016 um 19:18:11, schrieb Scott Kostyshak 

> On Fri, Apr 01, 2016 at 04:00:20PM -0700, Pavel Sanda wrote:
> > Georg Baum wrote:
> > > Where can I get a 
> > > current list of the email addresses of the translators?
> > 
> > Headers of .po files usually contains the last translator,
> 
> This is what Kornel's script takes care of automatically.

+ comparing with information at this side: http://www.lyx.org/I18n
The entries are not always identical.

> Scott
> 
> > git log should help in case the mail is missing.
> > I would CC lyx doc list as well.

Kornel

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

Re: Issues to discuss for 2.2.0rc1

2016-04-01 Thread Pavel Sanda 
Scott Kostyshak wrote:
> > Headers of .po files usually contains the last translator,
> 
> This is what Kornel's script takes care of automatically.

I just send bunch of direct emails for the translators. 
Lets see. P

Re: Issues to discuss for 2.2.0rc1

2016-04-01 Thread Scott Kostyshak 
On Fri, Apr 01, 2016 at 04:00:20PM -0700, Pavel Sanda wrote:
> Georg Baum wrote:
> > Where can I get a 
> > current list of the email addresses of the translators?
> 
> Headers of .po files usually contains the last translator,

This is what Kornel's script takes care of automatically.

Scott

> git log should help in case the mail is missing.
> I would CC lyx doc list as well.



signature.asc
Description: PGP signature

Re: Issues to discuss for 2.2.0rc1

2016-04-01 Thread Pavel Sanda 
Georg Baum wrote:
> Where can I get a 
> current list of the email addresses of the translators?

Headers of .po files usually contains the last translator,
git log should help in case the mail is missing.
I would CC lyx doc list as well.

Pavel

Re: Issues to discuss for 2.2.0rc1

2016-03-30 Thread Georg Baum 
Scott Kostyshak wrote:

> Do you think Monday (April 4) is enough time? That would give the
> weekend, at least.

OK, I'll try that.

>> Where can I get a
>> current list of the email addresses of the translators?
> 
> Others have taken care of contacting the translators, so I'm not sure
> what the best way is. Note that if you run
> ctest -R "check_translators"
> it will fail and in Testing/Temporary/LastTest.log there is a lot of
> useful information (thanks to Kornel) regarding the email addresses.
> I attach the file.

Thanks. I'll send the email tomorrow morning, I was not able anymore to sort 
out everything today.


Georg

Re: Issues to discuss for 2.2.0rc1

2016-03-30 Thread Georg Baum 
Jean-Marc Lasgouttes wrote:

> I get your point. Anyway I still think there would be value in compiling
> LyX on windows with several Qt and compilers. The fact that we do that
> in Linux has been very useful IMO.

Definitely. I always try to compile my stuff with as many 
compilers/platforms as possible as well. I was only arguing for the case 
that the resources do only allow one compiler/qt combination.


Georg

Re: Issues to discuss for 2.2.0rc1

2016-03-30 Thread Jean-Marc Lasgouttes 

Le 29/03/2016 22:47, Georg Baum a écrit :

This is your choice anyway. But then you'll have to cope with the
windows specific bugs that we may have, with fewer hints about what goes
wrong.


IMHO this is not the choice of Uwe alone. The windows installer is provided
under the name of the LyX project, as the official windows build, and not as
a third party contribution. Therefore, if the installer contains a buggy
build, it will damage the reputation of the LyX project. To avoid
misunderstandings: I do not say that Uwe did not test thoroughly, or that
the build _is_ buggy, but experience tells that there is a certain risk that
it _might_ be buggy if only one person did test.


I get your point. Anyway I still think there would be value in compiling 
LyX on windows with several Qt and compilers. The fact that we do that 
in Linux has been very useful IMO.


JMarc

Re: Issues to discuss for 2.2.0rc1

2016-03-29 Thread Scott Kostyshak 
On Mon, Mar 28, 2016 at 09:59:17AM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > On Sun, Mar 27, 2016 at 11:45:33AM +0200, Georg Baum wrote:
> >> Pavel Sanda wrote:
> >
> >> It is highest time to call for reviews. The last call is here:
> >> http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg07949.html
> >> 
> >> Scott, I can do that if you like.
> > 
> > Yes, please do. Thanks for taking care of that.
> 
> Sorry, I forgot to ask: Which deadline shall I set?

Do you think Monday (April 4) is enough time? That would give the
weekend, at least.

> Where can I get a 
> current list of the email addresses of the translators?

Others have taken care of contacting the translators, so I'm not sure
what the best way is. Note that if you run
ctest -R "check_translators"
it will fail and in Testing/Temporary/LastTest.log there is a lot of
useful information (thanks to Kornel) regarding the email addresses.
I attach the file.

Scott
Start testing: Mar 30 01:36 EDT
--
5062/5062 Testing: check_translators
5062/5062 Test: check_translators
Command: "/usr/bin/perl" 
"/home/scott/lyxbuilds/master/repo/development/checkurls/getTranslators.pl"
Directory: /home/scott/lyxbuilds/master/CMakeBuild
"check_translators" start time: Mar 30 01:36 EDT
Output:
--
Parsed "http://www.lyx.org/I18n-trunk;
Found 37 po-files with valid translator entry
(078%) Arabic: ar.po, mail = "Hatim 
Alahmadi" 
(078%) Different name in po:   Arabic: ar.po, mail = "Hatim 
Alahmady" 
(073%) Basque: eu.po, mail = "Iñaki 
Larrañaga Murgoitio" 
(041%) Catalan:ca.po, mail = "joan" 

(055%) Chinese (simplified):   zh_CN.po,  mail = "Yihui 
Xie" 
(091%) Chinese (traditional):  zh_TW.po,  mail = 
"Mingyi Wu" 
(090%) Czech:  cs.po, mail = "Pavel 
Sanda" 
(052%) Danish: da.po, mail = 
"Jesper Stemann Andersen" 
(038%) Dutch:  nl.po, mail = "Timo 
Kluck" 
(056%) Finnish:fi.po, mail = 
"Martin Vermeer" 
(056%) Different mail in po:   Finnish:fi.po, mail = 
"Jari-Matti Mäkelä" 
(100%) French: fr.po, mail = 
"Jean-Pierre Chrétien" 
(043%) Galician:   gl.po, mail = "Ramon 
Flores" 
(099%) German: de.po, mail = 
"Jürgen Spitzmüller" 
(099%) Different mail in po:   German: de.po, mail = "Uwe 
Stöhr" 
(044%) Greek:  el.po, mail = 
"Οδυσσέας Δαγκλής" 
(055%) Hebrew: he.po, mail = "Gilad 
Orr" 
(055%) Different mail in po:   Hebrew: he.po, mail = "Guy 
Rutenberg" 
(063%) Hungarian:  hu.po, mail = "Szőke 
Sándor" 
(077%) Indonesian: id.po, mail = 
"Waluyo Adi Siswanto" 
(093%) Interlingua:ia.po, mail = 
"G.Sora" 
(093%) Different name in po:   Interlingua:ia.po, mail = 
"Giovanni Sora" 
(100%) Italian:it.po, mail = 
"Enrico Forestieri" 
(099%) Japanese:   ja.po, mail = "Koji 
Yokota" 
(099%) Different mail in po:   Japanese:   ja.po, mail = "Koji 
Yokota" 
(096%) Norwegian (Bokmål):nb.po, mail = "Helge 
Hafting" 
(096%) Different mail in po:   Norwegian (Bokmål):nb.po, mail = "Helge 
Hafting" 
(078%) Norwegian (Nynorsk):nn.po, mail = "Ingar 
Pareliussen" <>
(067%) Polish: pl.po, mail = 
"Michał Fita" 
(091%) Portuguese: pt.po, mail = 
"Susana Barbosa" 
(091%) Different mail in po:   Portuguese: pt_PT.po,  mail = "Jorge 
Pinto" 
(099%) Missing in page:Portuguese (Brazilian): pt_BR.po,  mail = 
"Georger Araujo"

Re: Issues to discuss for 2.2.0rc1

2016-03-29 Thread Georg Baum 
Jean-Marc Lasgouttes wrote:

> Le 27/03/2016 21:38, Uwe Stöhr a écrit :
>> As I just wrote in the other thread I prefer Qt 5.6.
>> I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6
>> version. However, for the final release I won't maintain/offer support
>> for a Qt 5.5.1 build. Due to lack of time I will have to focus on one
>> version and Qt 5.6 offers a long term support, meaning I can assume that
>> this version will be supported by the Qt people for the full life time
>> of LyX 2.2.

If you don't have the resources to do two builds (which I can perfectly 
understand), then you can as well use MSVC2010 and qt 5.5.1 for the whole 
life time of LyX 2.2. The only thing you need to ensure is not to delete  
the MSVC and Qt installation on your development machine. Then you will be 
able to build any upcoming 2.2 LyX version. If you have a hardware problem 
and cannot use your machine anymore we can still decide what to do when this 
happens. Switching to MSVC2015 for LyX 2.2.x would not be worse than 
switching right now, it would recieve a similar amount of testing.

> Long term support is about what happens for the coming years.
> 
> Separate builds is more about understanding quickly what bugs come from
> the compiler or Qt. I do not anticipate this being needed after 2.2.1.
> 
> This is your choice anyway. But then you'll have to cope with the
> windows specific bugs that we may have, with fewer hints about what goes
> wrong.

IMHO this is not the choice of Uwe alone. The windows installer is provided 
under the name of the LyX project, as the official windows build, and not as 
a third party contribution. Therefore, if the installer contains a buggy 
build, it will damage the reputation of the LyX project. To avoid 
misunderstandings: I do not say that Uwe did not test thoroughly, or that 
the build _is_ buggy, but experience tells that there is a certain risk that 
it _might_ be buggy if only one person did test.

> What is nice with Linux is that we do have naturally this diversity
> (Qt4/Qt5, gcc/clang).
> 
> On the bright side, chromium has been ported to VC++2015 and several
> compiler bugs have been fixed in the process:
> https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/

This is one side of the story, and at a much smaller scale we made similar 
experiences: http://www.lyx.org/trac/changeset/34858/lyxsvn or 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557.

The other side of the story are application bugs which are uncovered by new 
compiler versions. We had those as well when we introduced clang support.

Finally, there are cases where we do not know whether it is a compiler issue 
or a LyX bug, like http://www.lyx.org/trac/ticket/9892 or 
http://www.lyx.org/trac/ticket/10009.

Building the official 2.2.0 release with MSVC2015 would really make me 
nervous:

- We would throw away all windows specific testing effort of the beta 
testers.
- There is a mysterious crash with the MSVC2015 
http://www.lyx.org/trac/ticket/10009 which does not happen with a merged 
build. Since we do not understand why a merged build "fixes" the crash we do 
not know what other problems might be created by the same cause.
- We would ignore standard best practice in professional software 
development (which would be to switch compilers at the beginning of a 
development cycle, not right before a release).

If we build 2.2.0 with MSVC2015 we should label the windows build as 
experimental IMHO.


Georg

Re: Issues to discuss for 2.2.0rc1

2016-03-29 Thread Jean-Marc Lasgouttes 

Le 27/03/2016 21:38, Uwe Stöhr a écrit :

As I just wrote in the other thread I prefer Qt 5.6.
I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6
version. However, for the final release I won't maintain/offer support
for a Qt 5.5.1 build. Due to lack of time I will have to focus on one
version and Qt 5.6 offers a long term support, meaning I can assume that
this version will be supported by the Qt people for the full life time
of LyX 2.2.


Long term support is about what happens for the coming years.

Separate builds is more about understanding quickly what bugs come from 
the compiler or Qt. I do not anticipate this being needed after 2.2.1.


This is your choice anyway. But then you'll have to cope with the 
windows specific bugs that we may have, with fewer hints about what goes 
wrong.


What is nice with Linux is that we do have naturally this diversity 
(Qt4/Qt5, gcc/clang).


On the bright side, chromium has been ported to VC++2015 and several 
compiler bugs have been fixed in the process:

https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/

JMarc

Re: Issues to discuss for 2.2.0rc1

2016-03-28 Thread Georg Baum 
Scott Kostyshak wrote:

> On Sun, Mar 27, 2016 at 11:45:33AM +0200, Georg Baum wrote:
>> Pavel Sanda wrote:
>
>> It is highest time to call for reviews. The last call is here:
>> http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg07949.html
>> 
>> Scott, I can do that if you like.
> 
> Yes, please do. Thanks for taking care of that.

Sorry, I forgot to ask: Which deadline shall I set? Where can I get a 
current list of the email addresses of the translators?


Georg

Re: Issues to discuss for 2.2.0rc1

2016-03-27 Thread Scott Kostyshak 
On Sun, Mar 27, 2016 at 09:38:34PM +0200, Uwe Stöhr wrote:
> Am 20.03.2016 um 21:48 schrieb Scott Kostyshak:
> 
> >Peter stated [1] that the patch is not necessary for compilation with
> >MSVC 2010.
> 
> But it doesn't harm then, see my today's post in the plans thread.
> 
> >It seems the majority opinion is to release rc1 (and final
> >2.2.0) with Qt 5.5.1 compiled with MSVC 2010. Uwe, are you OK with that?
> 
> As I just wrote in the other thread I prefer Qt 5.6.
> I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6
> version. However, for the final release I won't maintain/offer support for a
> Qt 5.5.1 build. Due to lack of time I will have to focus on one version and
> Qt 5.6 offers a long term support, meaning I can assume that this version
> will be supported by the Qt people for the full life time of LyX 2.2.
> 
> I hope you can understand my decision.

Yes, I do think I understand and you make good points. Qt 5.6 has the
advantages that:

1. You tested it and it works well for you.

2. It is faster for you.

3. It has long-term support.

I hope you can understand the opinions of others that there are
disadvantages of using Qt 5.6:

1. It requires switching compilers. I personally don't know much about
the dangers of this, but some LyX developers do know a lot about this
topic and they are worried. If someone knows more than I do about a
topic, I trust them more than I do myself.

2. Although you tested and it works for you, no one else has tested.

Scott


signature.asc
Description: PGP signature

Re: Issues to discuss for 2.2.0rc1

2016-03-27 Thread Uwe Stöhr 

Am 20.03.2016 um 21:48 schrieb Scott Kostyshak:


Peter stated [1] that the patch is not necessary for compilation with
MSVC 2010.


But it doesn't harm then, see my today's post in the plans thread.


It seems the majority opinion is to release rc1 (and final
2.2.0) with Qt 5.5.1 compiled with MSVC 2010. Uwe, are you OK with that?


As I just wrote in the other thread I prefer Qt 5.6.
I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6 
version. However, for the final release I won't maintain/offer support 
for a Qt 5.5.1 build. Due to lack of time I will have to focus on one 
version and Qt 5.6 offers a long term support, meaning I can assume that 
this version will be supported by the Qt people for the full life time 
of LyX 2.2.


I hope you can understand my decision.

regards Uwe

Re: Issues to discuss for 2.2.0rc1

2016-03-27 Thread Scott Kostyshak 
On Sun, Mar 27, 2016 at 11:45:33AM +0200, Georg Baum wrote:
> Pavel Sanda wrote:
> 
> > I keep track of missing things in layouttranslations.review.
> > In last releases when strings were frozen, I wrote to all translators to
> > check few additional items.
> > 
> > I missed the freeze-string message on the dev list to react appropriately
> > at the time; I still planned to send something, but overloaded by another
> > work these weeks, sorry.
> > 
> > What needs to be done is to list new strings, ask all active translators
> > to ack it/fix it and manually keep track if any of items in can be cleaned
> > up or prhaps ask on users lists, someone new around can potentially help.
> 
> Attached are the changes we would get if we updated all translations from 
> the .po files. Since the languages bg, ko and sl are completely unreviewed, 
> I would propose to overtake the new translations for these languages from 
> the .po files.
> 
> It is highest time to call for reviews. The last call is here: 
> http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg07949.html
> 
> Scott, I can do that if you like.

Yes, please do. Thanks for taking care of that.

Scott


signature.asc
Description: PGP signature

Re: Issues to discuss for 2.2.0rc1

2016-03-27 Thread Georg Baum 
Pavel Sanda wrote:

> I keep track of missing things in layouttranslations.review.
> In last releases when strings were frozen, I wrote to all translators to
> check few additional items.
> 
> I missed the freeze-string message on the dev list to react appropriately
> at the time; I still planned to send something, but overloaded by another
> work these weeks, sorry.
> 
> What needs to be done is to list new strings, ask all active translators
> to ack it/fix it and manually keep track if any of items in can be cleaned
> up or prhaps ask on users lists, someone new around can potentially help.

Attached are the changes we would get if we updated all translations from 
the .po files. Since the languages bg, ko and sl are completely unreviewed, 
I would propose to overtake the new translations for these languages from 
the .po files.

It is highest time to call for reviews. The last call is here: 
http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg07949.html

Scott, I can do that if you like.


Georgdiff --git a/lib/layouttranslations b/lib/layouttranslations
index 88fcb5d..7bf7bd8 100644
--- a/lib/layouttranslations
+++ b/lib/layouttranslations
@@ -10,10 +10,10 @@ Translation ar
 	"Acknowledgement" "اعتراف بالجميل"
 	"Algorithm" "الخوارزم"
 	"Assumption" "فرضية"
-	"Axiom" "مسلمة"
+	"Axiom" "مُسلّمة"
 	"Case" "حالة"
 	"Chart" "جدول بياني"
-	"Claim" "مطلب"
+	"Claim" "متطلب"
 	"Conclusion" "استنتاج"
 	"Condition" "شرط"
 	"Conjecture" "حدس"
@@ -23,23 +23,23 @@ Translation ar
 	"Example" "مثال"
 	"Exercise" "تمرين"
 	"Fact" "حقيقة"
-	"Graph[[mathematical]]" "رسم بياني[[رياضيات]]"
+	"Graph[[mathematical]]" "رسم بياني"
 	"Lemma" "قضية مساعدة"
 	"List of Algorithms" "قائمة الخوارزميات"
 	"List of Charts" "قائمة الجداول البيانية"
-	"List of Graphs[[mathematical]]" "قائمة الرسوم الرياضية[[رياضيات]]"
+	"List of Graphs[[mathematical]]" "قائمة الرسوم البيانية"
 	"List of Schemes" "قائمة المخططات"
 	"List of Tableaux" "قائمة الجداول"
-	"Listing" "قوائم"
-	"Listings[[List of Listings]]" "قوائم[[قائمة القوائم]]"
+	"Listing" "عمل قوائم"
+	"Listings[[List of Listings]]" "القوائم"
 	"Notation" "تدوين"
 	"Note" "ملاحظة"
 	"Problem" "مشكلة"
 	"Proof" "برهان"
 	"Property" "خاصية"
-	"Proposition" "فرضية"
+	"Proposition" "اقتراح"
 	"Question" "سؤال"
-	"Remark" "ملاحظة"
+	"Remark" "تنبيه"
 	"Scheme" "مخطط"
 	"Solution" "حل"
 	"Summary" "موجز"
@@ -82,7 +82,7 @@ Translation bg
 	"Question" "Въпрос"
 	"Remark" "Remark"
 	"Scheme" "Scheme"
-	"Solution" "Solution"
+	"Solution" "Решение"
 	"Summary" "Обобщение"
 	"Tableau" "Tableau"
 	"Theorem" "Теорема"
@@ -445,7 +445,7 @@ Translation fi
 	"List of Schemes" "Kuvausten lettelo"
 	"List of Tableaux" "Taulujen luettelo"
 	"Listing" "Listaus"
-	"Listings[[List of Listings]]" "Listausten luettelo"
+	"Listings[[List of Listings]]" "Ohjelmalistausten luettelo"
 	"Notation" "Merkintätapa"
 	"Note" "Muistiinpano"
 	"Problem" "Ongelma"
@@ -775,7 +775,7 @@ Translation ja
 	"Listing" "プログラムリスト"
 	"Listings[[List of Listings]]" "プログラムリスト"
 	"Notation" "記法"
-	"Note" "注釈"
+	"Note" "註釈"
 	"Problem" "問題"
 	"Proof" "証明"
 	"Property" "性質"
@@ -795,7 +795,7 @@ Translation ko
 	"Assumption" "Assumption"
 	"Axiom" "Axiom"
 	"Case" "Case"
-	"Chart" "Chart"
+	"Chart" "차트"
 	"Claim" "Claim"
 	"Conclusion" "Conclusion"
 	"Condition" "Condition"
@@ -806,17 +806,17 @@ Translation ko
 	"Example" "Example"
 	"Exercise" "Exercise"
 	"Fact" "Fact"
-	"Graph[[mathematical]]" "Graph"
+	"Graph[[mathematical]]" "그래프"
 	"Lemma" "Lemma"
 	"List of Algorithms" "알고리듬 목록"
-	"List of Charts" "List of Charts"
-	"List of Graphs[[mathematical]]" "List of Graphs"
+	"List of Charts" "차트 목록"
+	"List of Graphs[[mathematical]]" "그래프 목록"
 	"List of Schemes" "List of Schemes"
 	"List of Tableaux" "List of Tableaux"
 	"Listing" "Listing"
 	"Listings[[List of Listings]]" "Listings"
 	"Notation" "Notation"
-	"Note" "노우트(Note)"
+	"Note" "노트(Note)"
 	"Problem" "Problem"
 	"Proof" "Proof"
 	"Property" "Property"
@@ -855,7 +855,7 @@ Translation nb
 	"List of Schemes" "Struktruformler"
 	"List of Tableaux" "Tablåer"
 	"Listing" "«Listing»"
-	"Listings[[List of Listings]]" "Liste over kildekode"
+	"Listings[[List of Listings]]" "Liste over programlister"
 	"Notation" "Notasjon"
 	"Note" "Merknad"
 	"Problem" "Problem"
@@ -896,7 +896,7 @@ Translation nl
 	"List of Schemes" "Lijst van Schema's"
 	"List of Tableaux" "Lijst van Tableaus"
 	"Listing" "Listing"
-	"Listings[[List of Listings]]" "Lijst van Listings"
+	"Listings[[List of Listings]]" "Listings"
 	"Notation" "Notatie"
 	"Note" "Noot"

Re: Issues to discuss for 2.2.0rc1

2016-03-25 Thread Georg Baum 
José Matos wrote:

> For python 3 the strings are now unicode strings and so all works:
> 
> $ ipython3 --no-banner
> 
> In [1]: type( "123%s" % "")
> Out[1]: str
> 
> In [2]: type( "123%s" % u"")
> Out[2]: str
> 
> So a safe bet would be to prefix all the strings with an u, overkill sure
> but it will surely work. :-D

Many thanks for the explanation, now I understand what happens. I took your 
+1 and committed a version that works both with python2 and python3. I 
tested that by regenerating po/lyx.pot and lib/layouttranslations with 
python 2.7.9 and the unmodified script, python 2.7.9 and the modified 
script, and python 3.4.2 and the modified script. All three runs produced 
the same results.


Georg

Re: Issues to discuss for 2.2.0rc1

2016-03-24 Thread José Matos 
On Wednesday, March 23, 2016 9:36:45 PM WET Georg Baum wrote:
> You are right. I did only test the patch manually with some of the 
> conversions, and they did work. Now I did test it more systematically in
> the  build system, and it turned out that in some cases the u prefix is
> needed, but not in all. Why? Or isn this code simply not called? There were
> also some encode/decode calls that do now need to be removed (here I
> understand why).

The reason is explained here:

$ ipython --no-banner

In [1]: type( "123%s" % "")
Out[1]: str

In [2]: type( "123%s" % u"")
Out[2]: unicode

The issue is that, in python 2, if you interpolate (the % operator) a string 
with a string you get a string.

If you interpolate a string using an unicode string you get an unicode string.

In all those cases where you pass an string read from file, where you declared 
the encoding to be utf-8 you are already using an unicode string and so the 
interpolation results in a unicode string and all works.

For python 3 the strings are now unicode strings and so all works:

$ ipython3 --no-banner

In [1]: type( "123%s" % "")
Out[1]: str

In [2]: type( "123%s" % u"")
Out[2]: str

So a safe bet would be to prefix all the strings with an u, overkill sure but 
it will surely work. :-D

Incidentally this is the reason why I insisted that if we support python 3 
with should go at least with 3.3. In python 3.3 the u string prefix was 
reintroduced in the language, where it is a no-op, allowing to use the same 
for python 2 and python 3.

> Attached is the updated patch, but since I do not completely understand it
> I  think we should postpone it.
> 
> Georg

It is just a matter of testing it and where it fails to add the u prefix to 
the string. :-)

Thank you for taking care of this.
-- 
José Abílio

Re: Issues to discuss for 2.2.0rc1

2016-03-24 Thread Pavel Sanda 
Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > - What am I missing?
> 
> While testing the changed lyx_pot.py file I did also update 
> lib/layouttranslations. The result is attached. Either I missed it, or there 
> was no call for confirmation of changed layout translations. If there was no 
> call, then we definitely need it before releasing 2.2.0, since the strings 
> will be fixed throughout the release cycle.
> 
> We had a procedure for this, but the only thing I could find was  
> http://www.lyx.org/trac/ticket/7386, which is not the latest version.
> 
> Pavel, dou you remember where the procedure is documented?

I keep track of missing things in layouttranslations.review.
In last releases when strings were frozen, I wrote to all translators to check 
few
additional items.

I missed the freeze-string message on the dev list to react appropriately
at the time; I still planned to send something, but overloaded by another
work these weeks, sorry.

What needs to be done is to list new strings, ask all active translators
to ack it/fix it and manually keep track if any of items in can be cleaned
up or prhaps ask on users lists, someone new around can potentially help.

Pavel

Re: Issues to discuss for 2.2.0rc1

2016-03-23 Thread Georg Baum 
Scott Kostyshak wrote:

> - What am I missing?

While testing the changed lyx_pot.py file I did also update 
lib/layouttranslations. The result is attached. Either I missed it, or there 
was no call for confirmation of changed layout translations. If there was no 
call, then we definitely need it before releasing 2.2.0, since the strings 
will be fixed throughout the release cycle.

We had a procedure for this, but the only thing I could find was  
http://www.lyx.org/trac/ticket/7386, which is not the latest version.

Pavel, dou you remember where the procedure is documented?


Georg

diff --git a/lib/layouttranslations b/lib/layouttranslations
index 325b9a2..1ab8e8d 100644
--- a/lib/layouttranslations
+++ b/lib/layouttranslations
@@ -10,10 +10,10 @@ Translation ar
 	"Acknowledgement" "اعتراف بالجميل"
 	"Algorithm" "الخوارزم"
 	"Assumption" "فرضية"
-	"Axiom" "مسلمة"
+	"Axiom" "مُسلّمة"
 	"Case" "حالة"
 	"Chart" "جدول بياني"
-	"Claim" "مطلب"
+	"Claim" "متطلب"
 	"Conclusion" "استنتاج"
 	"Condition" "شرط"
 	"Conjecture" "حدس"
@@ -23,23 +23,23 @@ Translation ar
 	"Example" "مثال"
 	"Exercise" "تمرين"
 	"Fact" "حقيقة"
-	"Graph[[mathematical]]" "رسم بياني[[رياضيات]]"
+	"Graph[[mathematical]]" "رسم بياني"
 	"Lemma" "قضية مساعدة"
 	"List of Algorithms" "قائمة الخوارزميات"
 	"List of Charts" "قائمة الجداول البيانية"
-	"List of Graphs[[mathematical]]" "قائمة الرسوم الرياضية[[رياضيات]]"
+	"List of Graphs[[mathematical]]" "قائمة الرسوم البيانية"
 	"List of Schemes" "قائمة المخططات"
 	"List of Tableaux" "قائمة الجداول"
-	"Listing" "قوائم"
-	"Listings[[List of Listings]]" "قوائم[[قائمة القوائم]]"
+	"Listing" "عمل قوائم"
+	"Listings[[List of Listings]]" "القوائم"
 	"Notation" "تدوين"
 	"Note" "ملاحظة"
 	"Problem" "مشكلة"
 	"Proof" "برهان"
 	"Property" "خاصية"
-	"Proposition" "فرضية"
+	"Proposition" "اقتراح"
 	"Question" "سؤال"
-	"Remark" "ملاحظة"
+	"Remark" "تنبيه"
 	"Scheme" "مخطط"
 	"Solution" "حل"
 	"Summary" "موجز"
@@ -441,7 +441,7 @@ Translation fi
 	"List of Schemes" "Kuvausten lettelo"
 	"List of Tableaux" "Taulujen luettelo"
 	"Listing" "Listaus"
-	"Listings[[List of Listings]]" "Listausten luettelo"
+	"Listings[[List of Listings]]" "Ohjelmalistausten luettelo"
 	"Notation" "Merkintätapa"
 	"Note" "Muistiinpano"
 	"Problem" "Ongelma"
@@ -771,7 +771,7 @@ Translation ja
 	"Listing" "プログラムリスト"
 	"Listings[[List of Listings]]" "プログラムリスト"
 	"Notation" "記法"
-	"Note" "注釈"
+	"Note" "註釈"
 	"Problem" "問題"
 	"Proof" "証明"
 	"Property" "性質"
@@ -847,7 +847,7 @@ Translation nb
 	"List of Schemes" "Struktruformler"
 	"List of Tableaux" "Tablåer"
 	"Listing" "«Listing»"
-	"Listings[[List of Listings]]" "Liste over kildekode"
+	"Listings[[List of Listings]]" "Liste over programlister"
 	"Notation" "Notasjon"
 	"Note" "Merknad"
 	"Problem" "Problem"
@@ -1044,11 +1044,11 @@ Translation pt_PT
 	"Example" "Exemplo"
 	"Exercise" "Exercício"
 	"Fact" "Facto"
-	"Graph[[mathematical]]" "Grafo"
+	"Graph[[mathematical]]" "Gráfico"
 	"Lemma" "Lema"
 	"List of Algorithms" "Lista de Algoritmos"
 	"List of Charts" "Lista de Mapas"
-	"List of Graphs[[mathematical]]" "Lista de Grafos"
+	"List of Graphs[[mathematical]]" "Lista de Gráficos"
 	"List of Schemes" "Lista de Esquemas"
 	"List of Tableaux" "Lista de Quadros"
 	"Listing" "Listagem"
@@ -1059,7 +1059,7 @@ Translation pt_PT
 	"Proof" "Prova"
 	"Property" "Propriedade"
 	"Proposition" "Proposição"
-	"Question" "Questão"
+	"Question" "Pergunta"
 	"Remark" "Observação"
 	"Scheme" "Esquema"
 	"Solution" "Solução"

Re: Issues to discuss for 2.2.0rc1

2016-03-23 Thread Georg Baum 
José Matos wrote:

> So Georg if you got the code to work with python2 in you have my +1. :-)

Thanks for looking at this.

> There are two possible source of problems:
> 1) input files should be utf-8. Since I think that is the case the patch
> is safe.

Yes, all input files are encoded in utf8, I checked that.

> 2) to have some that looks like this
> 
> print("#$%&/", file=out) where we will get an error:
> 
> ...
> TypeError: must be unicode, not str
> 
> Those are easy to catch. And the solution is to prefix the string with an
> u (unicode string)
> 
> print(u"#$%&/", file=out) where we will get an error:
> 
> On a quick glance at the code I expect this to work.

You are right. I did only test the patch manually with some of the 
conversions, and they did work. Now I did test it more systematically in the 
build system, and it turned out that in some cases the u prefix is needed, 
but not in all. Why? Or isn this code simply not called? There were also 
some encode/decode calls that do now need to be removed (here I understand 
why).

Attached is the updated patch, but since I do not completely understand it I 
think we should postpone it.


Georg
diff --git a/po/lyx_pot.py b/po/lyx_pot.py
index 432a126..71481f2 100755
--- a/po/lyx_pot.py
+++ b/po/lyx_pot.py
@@ -19,6 +19,7 @@
 from __future__ import print_function
 
 import sys, os, re, getopt
+import io
 
 def relativePath(path, base):
 '''return relative path from top source dir'''
@@ -43,7 +44,7 @@ def writeString(outfile, infile, basefile, lineno, string):
 
 def ui_l10n(input_files, output, base):
 '''Generate pot file from lib/ui/*'''
-output = open(output, 'w')
+output = io.open(output, 'w', encoding='utf_8')
 Submenu = re.compile(r'^[^#]*Submenu\s+"([^"]*)"', re.IGNORECASE)
 Popupmenu = re.compile(r'^[^#]*PopupMenu\s+"[^"]+"\s+"([^"]*)"', re.IGNORECASE)
 IconPalette = re.compile(r'^[^#]*IconPalette\s+"[^"]+"\s+"([^"]*)"', re.IGNORECASE)
@@ -51,7 +52,7 @@ def ui_l10n(input_files, output, base):
 Item = re.compile(r'[^#]*Item\s+"([^"]*)"', re.IGNORECASE)
 TableInsert = re.compile(r'[^#]*TableInsert\s+"([^"]*)"', re.IGNORECASE)
 for src in input_files:
-input = open(src)
+input = io.open(src, encoding='utf_8')
 for lineno, line in enumerate(input.readlines()):
 if Submenu.match(line):
 (string,) = Submenu.match(line).groups()
@@ -125,7 +126,7 @@ def layouts_l10n(input_files, output, base, layouttranslations):
 
 # read old translations if available
 try:
-input = open(output)
+input = io.open(output, encoding='utf_8')
 lang = ''
 for line in input.readlines():
 res = Comment.search(line)
@@ -147,8 +148,8 @@ def layouts_l10n(input_files, output, base, layouttranslations):
 continue
 res = KeyValPair.search(line)
 if res and lang != '':
-key = res.group(1).decode('utf-8')
-val = res.group(2).decode('utf-8')
+key = res.group(1)
+val = res.group(2)
 key = key.replace('\\"', '"').replace('', '\\')
 val = val.replace('\\"', '"').replace('', '\\')
 oldtrans[lang][key] = val
@@ -165,7 +166,7 @@ def layouts_l10n(input_files, output, base, layouttranslations):
 if 'wa' in languages:
 languages.remove('wa')
 
-out = open(output, 'w')
+out = io.open(output, 'w', encoding='utf_8')
 for src in input_files:
 readingDescription = False
 readingI18nPreamble = False
@@ -178,7 +179,7 @@ def layouts_l10n(input_files, output, base, layouttranslations):
 descStartLine = -1
 descLines = []
 lineno = 0
-for line in open(src).readlines():
+for line in io.open(src, encoding='utf_8').readlines():
 lineno += 1
 res = ClassDescription.search(line)
 if res != None:
@@ -381,7 +382,7 @@ def layouts_l10n(input_files, output, base, layouttranslations):
 
 ContextRe = re.compile(r'(.*)(\[\[.*\]\])')
 
-print('''# This file has been automatically generated by po/lyx_pot.py.
+print(u'''# This file has been automatically generated by po/lyx_pot.py.
 # PLEASE MODIFY ONLY THE LAGUAGES HAVING NO .po FILE! If you want to regenerate
 # this file from the translations, run `make ../lib/layouttranslations' in po.
 # Python polib library is needed for building the output file.
@@ -389,7 +390,7 @@ def layouts_l10n(input_files, output, base, layouttranslations):
 # This file should remain fixed during minor LyX releases.
 # For more comments see README.localization file.''', file=out)
 for lang in languages:
-print('\nTranslation %s' % lang, file=out)
+print(u'\nTranslation %s' % lang, file=out)
 if lang in list(oldtrans.keys()):

Re: Issues to discuss for 2.2.0rc1

2016-03-23 Thread José Matos 
On Tuesday, March 22, 2016 10:45:12 PM WET Georg Baum wrote:
> It would be great if somebody with good python kowledge can confirm that
> the  patch does not break anything with python2. If there is nobody who can
> easily confirm this then I propose to apply it after 2.2.0 is out, since it
> is not too urgent IMHO.
> 
> Georg

Without much time to test it I should say that the patch looks sensible and if 
necessary it is easy to revert.

And pre-phrasing the famous last words (tm) "I do not see how this patch could 
fail". ;-)

So Georg if you got the code to work with python2 in you have my +1. :-)

There are two possible source of problems:
1) input files should be utf-8. Since I think that is the case the patch is 
safe.

2) to have some that looks like this

print("#$%&/", file=out) where we will get an error:

...
TypeError: must be unicode, not str

Those are easy to catch. And the solution is to prefix the string with an u 
(unicode string)

print(u"#$%&/", file=out) where we will get an error:

On a quick glance at the code I expect this to work.
-- 
José Abílio

Re: Issues to discuss for 2.2.0rc1

2016-03-22 Thread Georg Baum 
Scott Kostyshak wrote:

> - I do not understand if we need to do something for #9979?

IMHO only if there is some volunteer who has a fix ready in time. The 
conditions for this bug are so special that it also can wait a little bit 
longer.

> - Georg has provided a patch to improve building with Python 3 here:
> https://www.mail-archive.com/search?l=mid=ncf3fj%24gqh%241%40ger.gmane.org
> Helge has tested that it works for him. Does anyone +1 the patch?

It would be great if somebody with good python kowledge can confirm that the 
patch does not break anything with python2. If there is nobody who can 
easily confirm this then I propose to apply it after 2.2.0 is out, since it 
is not too urgent IMHO.


Georg

Re: Issues to discuss for 2.2.0rc1

2016-03-21 Thread Jean-Marc Lasgouttes 

Le 21/03/2016 13:09, Joel Kulesza a écrit :

Indeed, I can spend some time and would be happy to have the community's
help to be able to build using the latest-and-greatest features.  Later
today I'll collect my thoughts and enumerate my (failed) approaches in a
separate email to the lyx-devel list, unless there are objections.


Please do. We will do our best t make compilation easy, or at least 
possible.


JMarc

Re: Issues to discuss for 2.2.0rc1

2016-03-21 Thread Joel Kulesza 
On Mon, Mar 21, 2016 at 5:06 AM, Stephan Witt  wrote:

>
> In case you’re able to spend some time I think we should find a way to put
> you on the track to build LyX yourself.
> It is an important thing to come to a "fail safe“ and redundant
> environment.


Indeed, I can spend some time and would be happy to have the community's
help to be able to build using the latest-and-greatest features.  Later
today I'll collect my thoughts and enumerate my (failed) approaches in a
separate email to the lyx-devel list, unless there are objections.

Re: Issues to discuss for 2.2.0rc1

2016-03-21 Thread Stephan Witt 
Am 21.03.2016 um 01:10 schrieb Joel Kulesza :
> 
> On Sun, Mar 20, 2016 at 4:48 PM, Scott Kostyshak  wrote:
> 
> #9992
> It is a crash because of a screen management tool. Because it is due to
> external software, I don't think we should consider this a rc1 blocker.
> There is a regression from the user perspective, and it would be nice to
> know whether different Qt versions lead to different behaviors. For
> example, if the crash is still experienced with 2.2.0rc1 compiled with
> Qt 4.8.6 (which I think is what 2.1.x was compiled with), then perhaps
> we can figure out what the change in LyX's code was.
> 
> 
> Please note that this it was not conclusively determined that this is due to 
> a screen management tool.  

Yes, this was a guess only. I’m not so confident either.
 
> Note also that this was on OSX using the newly implemented Retina support.  

I don’t think this matters. We had crashes with similar call stacks in the 
pre-HiDPI-past. 
IMO, things like that are caused by memory management or thread issues.
The biggest problem is the difficulty to reproduce the bug on other systems.

> Regardless, it cannot be reproduced to otherwise attribute it to something 
> else.  If/when other Qt versions are built against, I would be happy to 
> perform testing.  Regrettably, it seems I cannot build myself, but I would be 
> willing to test various installers.

In case you’re able to spend some time I think we should find a way to put you 
on the track to build LyX yourself.
It is an important thing to come to a "fail safe“ and redundant environment.

Stephan

Re: Issues to discuss for 2.2.0rc1

2016-03-20 Thread Joel Kulesza 
On Sun, Mar 20, 2016 at 4:48 PM, Scott Kostyshak  wrote:

>
> #9992
> It is a crash because of a screen management tool. Because it is due to
> external software, I don't think we should consider this a rc1 blocker.
> There is a regression from the user perspective, and it would be nice to
> know whether different Qt versions lead to different behaviors. For
> example, if the crash is still experienced with 2.2.0rc1 compiled with
> Qt 4.8.6 (which I think is what 2.1.x was compiled with), then perhaps
> we can figure out what the change in LyX's code was.
>
>
Please note that this it was not conclusively determined that this is due
to a screen management tool.  Note also that this was on OSX using the
newly implemented Retina support.  Regardless, it cannot be reproduced to
otherwise attribute it to something else.  If/when other Qt versions are
built against, I would be happy to perform testing.  Regrettably, it seems
I cannot build myself, but I would be willing to test various installers.

Re: Issues to discuss for 2.2.0rc1

2016-03-20 Thread Guillaume Munch 

Le 20/03/2016 20:48, Scott Kostyshak a écrit :


#9963
Although this is a regression, we cannot reproduce and I don't think it
is a blocker so unless someone has an idea I think we must postpone.


I agree. Also my patch worked around the most annoying part of the bug 
already.

Issues to discuss for 2.2.0rc1

2016-03-20 Thread Scott Kostyshak 
Dear all,

We are closer to 2.2.0rc1. The following are the issues that I think we
should address before 2.2.0rc1 (and 2.2.0 final).

Regarding the tickets that we have with a 2.2.0 milestone:

#9892
Peter stated [1] that the patch is not necessary for compilation with
MSVC 2010. It seems the majority opinion is to release rc1 (and final
2.2.0) with Qt 5.5.1 compiled with MSVC 2010. Uwe, are you OK with that?
Is there a critical Qt bug that only affects LyX if we compile against
5.5.1 and does not affect LyX when compiled with 5.6.0? Although 5.6.0
would bring new features, such as better support for HiDPI, I think
stability is more important. We can provide unofficial installers using
Qt 5.6.0.

#9992
It is a crash because of a screen management tool. Because it is due to
external software, I don't think we should consider this a rc1 blocker.
There is a regression from the user perspective, and it would be nice to
know whether different Qt versions lead to different behaviors. For
example, if the crash is still experienced with 2.2.0rc1 compiled with
Qt 4.8.6 (which I think is what 2.1.x was compiled with), then perhaps
we can figure out what the change in LyX's code was.

#9963
Although this is a regression, we cannot reproduce and I don't think it
is a blocker so unless someone has an idea I think we must postpone.

#9985
We don't know what the problem is but there is a workaround and no one
can reproduce, so I do not think this is a critical bug.

#10017
Sub-menus do not expand on Windows. This would be a critical bug but
only one user experienced the issue on beta2. Note that alpha1 did work
for the user. I think we should see if the user also sees the bug with
rc1 and for which Qt versions (assuming we do provide multiple
unofficial installers with different Qt versions).

#10019
Guillaume fixed some ui regressions. The patch seems short and logical
and Stephan has tested it on Mac. I would still like to see if someone
can test it on Windows before it is included. If anyone with Qt
knowledge can take a look at the patch, that would also be nice. I think
normally I would not want any .ui changes in at this point (for the
reasons I listed on that ticket), but since they are fixing regressions
it is hard to resist.

#10027
The 2.2.0 part of this bug just involves adding an "obsoleted" note.

Other topics that are not targeted to 2.2.0.

- I do not understand if we need to do something for #9979?

- Georg has provided a patch to improve building with Python 3 here:
https://www.mail-archive.com/search?l=mid=ncf3fj%24gqh%241%40ger.gmane.org
Helge has tested that it works for him. Does anyone +1 the patch?

- There are layouts that we want to update so that they work with newer
  versions of the class/style files that have been recently released.

- Regarding replacement of "long table" by "multi-pages table", José kindly
  made progress but we are still missing a full patch. José's progress is here:
https://www.mail-archive.com/search?l=mid=25133064.0sqmE3gEfi%40jamatos

- Enrico has provided a patch regarding separators here:
https://www.mail-archive.com/search?l=mid=20160313003332.GA8700%40giove
Even though it is a file format change, I think it would be nice to
include because otherwise users will have to get used to new behavior in
2.2.0 and then get used to changed behavior again in 2.3.0. I do not
understand the issue though since I rarely use separators. Guillaume or
José since you seem to understand the issue, can either of you give a +1
to the patch?

- What am I missing?

Scott

[1]
https://www.mail-archive.com/search?l=mid=56E2B241.9030001%40gmx.net


signature.asc
Description: PGP signature