Biblatex

[Jürgen Spitzmüller]

Biblatex support is ready over at the features/biblatex2 branch.

Of course we do not support the whole range of biblatex's feature set
natively, but we already support all that natbib/jurabib does and
substially more (features I'd like to add eventually include
refsection/refsegements and particularly so-called "qualified citation
lists").

Essentially, the current implementation introduces:

* Scanning and detection of the relevant files (package, styles)

* A GUI to
  - select biblatex engine(s) next to basic, jurabib, natbib,
  - set bibliography and citation style files (with default proposals)
  - set further biblatex package options (this field will later be also
used by natbib and jurabib, an old request)
  - set options to the \printbibliography command

* Automatic setting of backend option if bibtex[8] is selected

* Style files that define biblatex's citation styles for the GUI and
xhtml output

* Make the BibTeX inset biblatex-aware (i.e., output \printbibliography
and optional argument in the body and pass the bib files to
\addbibresource macros in the preamble)

Along the way, I had to polish and extend our biblio-related code at
many places in order to enable things. Consequently, nothing in the
code is longer hardcoded to bibtex, natbib or jurabib, but generalized
in a way that it can be adjusted in the respective style files to the
needs of the respective engine. I was able to replace some ad-hoc
additions for the sake of specific engines with general, transparent
and extensible code (while keeping the functionality). This also
allowed me to fix some bugs and implement some long-standing desiderata
(such as the display of uppercased names and full author lists in the
GUI), en passant.

I have put most energy into a design that enables portability between
the diverse citation engines as much as possible, so it should be very
easy to switch an existing document from, say, natbib to biblatex and
(to a limited degree, since the feature set is larger) back. This is
why the citation styles use a common set of cmd names rather than just
the corresponding latex name.

If you want to try and play with it, check out the features/biblatex2
branch (not the old features/biblatex branch).

I propose to merge this to master rather soon, to give it more testing
and iron out potential bugs.

Jürgen

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

Re: Testing of the 2.2.x Branch (esp Slowness)

[Jean-Pierre Chrétien]

Le 07/01/2017 à 02:05, Richard Heck a écrit :

We (specifically, Jean-Marc Lasgouttes) have recently made some changes
to the text rendering algorithms in LyX. We would appreciate it if those
who are able could compile and use the 2.2.x branch of the git
repository, so that these changes can receive sufficient testing before
we schedule the release of LyX 2.2.3.



I just finished updating the French version of the EmbeddedObjects manual using 
a fresh release compilation of 2.2.x. The only thing I noticed is a lot of messages


QFile::remove: Empty or null file name

in the calling shell window.

Configuration on Debian Jessie:
  Host type:   x86_64-unknown-linux-gnu
  Special build flags:  build=release c++11 std-regex use-hunspell
  C++ Compiler:g++ (4.9.2)
  C++ Compiler flags:   -std=c++11 -O2 -Wno-deprecated-declarations
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  4.8.6
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.2.3dev

--
Jean-Pierre

Re: UserGuide.lyx lyx2lyx error "unusual contents found"

[Scott Kostyshak]

On Sat, Dec 31, 2016 at 02:02:19PM +, Guenter Milde wrote:

> >> Is this a concern or should it be ignored?
> 
> > Can be ignored IMHO.
> 
> I'd prefer to convert them to the respective Unicode characters and do the
> replacement as preamble fallback macro definition.

Is there agreement this is the right thing to do?

Scott


signature.asc
Description: PGP signature

Re: doc/UserGuide systemF tests failing

[Scott Kostyshak]

On Wed, Dec 28, 2016 at 01:08:44PM +0100, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 28.12.2016, 11:41 + schrieb Guenter Milde:
> > I see. But as the tests should correspond to "normal" LyX behaviour,
> > we
> > should rather
> > 
> > a) fix the document: we can set a custom non-tex font that contains
> > the
> >    missing characters. This way a user just clicking "use non-TeX
> > fonts" and
> >    compiling will get the correct result.
> >    There are no side-effects with the default (TeX-fonts) setting.
> >    
> >    If there is a free suitable font, this is my preference.
> 
> I doubt you will find a free suitable font that is expected to be
> installed on every user's box so that "a user just clicking "'use non-
> TeX fonts' and compiling will get the correct result."

Until now we pretty much had such a font.

> > b) invert the test: as the document is not required to work with non-
> > TeX
> >    fonts but only reused for tests of all export formats, the failing
> > test
> >    does not mean there is a problem in LyX and can be ignored.
> 
> However, the UG is a quite good test file. It would be a pity to take
> it off the set just because the glyphs are missing.

I agree it is unfortunate.

> Ignoring the
> missing glyphs warning strikes me a better alternative.

Perhaps. Does anyone volunteer to do this work?

> >    -1 the document can no longer be used to test export with Unicode
> > fonts.
> >    
> >    If there is no suitable Unicode font, this is the correct way.
> >    For test with Unicode fonts, we could add a modified copy to the
> >    "dedicated test samples folder" autotests/export/latex/.
> 
> Then you would need to maintain that copy and update it every time the
> UG is updated. I doubt this will work.

For testing the full User Guide, yes. But for testing that the "old"
user guide works (which I think is still very useful), we do not have to
maintain anything.

In the meantime, tests are failing. I will plan to copy the old User
Guide to a separate test, invert the tests of the current User Guide for
system fonts, and open a bug report that corresponds to potential
improvements discussed here.

Scott


signature.asc
Description: PGP signature

Re: UserGuide.lyx lyx2lyx error "unusual contents found"

[Jürgen Spitzmüller]

Am Sonntag, den 08.01.2017, 10:24 -0500 schrieb Scott Kostyshak:
> OK then I guess we should invert the tests (and perhaps continue the
> debate in a bug report). The other possibility is the change the
> regex
> that checks for lyx2lyx errors to ignore these ones but that doesn't
> seem like a good idea.

I can try to fix this at the lyx2lyx level once I am out of the
biblatex tunnel.

Jürgen

> 
> Scott

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

Re: UserGuide.lyx lyx2lyx error "unusual contents found"

[Jürgen Spitzmüller]

Am Sonntag, den 08.01.2017, 09:24 -0500 schrieb Scott Kostyshak:
> > I'd prefer to convert them to the respective Unicode characters and
> > do the
> > replacement as preamble fallback macro definition.
> 
> Is there agreement this is the right thing to do?

No.

Jürgen

> 
> Scott

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

Re: doc/UserGuide systemF tests failing

[Jürgen Spitzmüller]

Am Sonntag, den 08.01.2017, 09:22 -0500 schrieb Scott Kostyshak:
> > I doubt you will find a free suitable font that is expected to be
> > installed on every user's box so that "a user just clicking "'use
> > non-
> > TeX fonts' and compiling will get the correct result."
> 
> Until now we pretty much had such a font.

Yes. But until now, we pretty much ignored the non-Western world (in
the English UG).

> In the meantime, tests are failing. I will plan to copy the old User
> Guide to a separate test, invert the tests of the current User Guide
> for
> system fonts, and open a bug report that corresponds to potential
> improvements discussed here.

OK.

Jürgen

> 
> Scott

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

Re: LyX 2.2 slowness

[Jean-Marc Lasgouttes]

Le 08/01/2017 à 18:00, Stephan Witt a écrit :

I tried the current master (commit 21259b66b5d36913aaf4dcded8aaac3254b04354) on 
Mac.
It seems to be fast with Qt5 - but I’m not sure how to verify that.

One thing I’ve noticed: the images in text are not shown immediately when 
scrolling
through the users guide. I didn’t investigate if the mentioned patch is causing 
this.
To make them appear one has to click in the main area or scroll again after 
stop.


I would be surprised that it is this particular patch, but this is 
definitely something we need to fix.


JMarc

Re: X-Apps

[Paul A. Rubin]

On 01/08/2017 11:51 AM, Stephan Witt wrote:

Am 08.01.2017 um 17:04 schrieb Paul A. Rubin :


At this point (having reloaded some programs), if I were to put the X-Apps at the 
end of their respective vectors and reconfigure LyX, none of the X-Apps would be 
selected. My default text editor would be notepad, which would require running the 
Wine emulator. My default PDF viewer would be Acrobat Reader (which would be okay 
with me). My default image viewer would be gimp, which I find much too cumbersome 
just for looking at an image. So I would end up having to edit the viewers in 
Tools > Preferences, which is exactly what I would be doing with the previous 
configuration script.

Putting the X-Apps last in their respective vectors helps anyone who has none 
of the other tools installed, so it's certainly better than nothing. I can 
understand your being concerned about users suddenly finding a different viewer 
than what they previously had, but my understanding is that the X-Apps are 
direct substitutes for evince, gedit and (I think) xv, so it makes sense to me 
that their precedence in the list would match the precedence assigned to the 
apps they're replacing.

What about adding xdg-open instead to the list of PDF-viewers. This should do 
the right thing on every distro, IMO.

Stephan
That would definitely work for me, provided that xdg-open was first 
rather than last on each list. Since it uses the system default 
applications, it seems to me it belongs at the start of the lists.


Paul

Re: UserGuide.lyx lyx2lyx error "unusual contents found"

[Jürgen Spitzmüller]

Am Sonntag, den 08.01.2017, 12:02 -0500 schrieb Scott Kostyshak:
> > I can try to fix this at the lyx2lyx level once I am out of the
> > biblatex tunnel.
> 
> OK.

Well, it turned out to be a pretty stupid typo of mine.

Should be cured now.

Jürgen

> 
> Scott

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

Re: Testing of the 2.2.x Branch (esp Slowness)

[Scott Kostyshak]

On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:

> The only thing I noticed is a
> lot of messages
> 
> QFile::remove: Empty or null file name
> 
> in the calling shell window.

We noticed the same thing at
https://www.mail-archive.com/search?l=mid=a15e9a60-11bb-c081-84cb-9b7f8536b163%40free.fr

but I could not figure out the root cause.

Scott


signature.asc
Description: PGP signature

Re: UserGuide.lyx lyx2lyx error "unusual contents found"

[Scott Kostyshak]

On Sun, Jan 08, 2017 at 04:09:41PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 08.01.2017, 09:24 -0500 schrieb Scott Kostyshak:
> > > I'd prefer to convert them to the respective Unicode characters and
> > > do the
> > > replacement as preamble fallback macro definition.
> > 
> > Is there agreement this is the right thing to do?
> 
> No.

OK then I guess we should invert the tests (and perhaps continue the
debate in a bug report). The other possibility is the change the regex
that checks for lyx2lyx errors to ignore these ones but that doesn't
seem like a good idea.

Scott


signature.asc
Description: PGP signature

Re: X-Apps

[Stephan Witt]

Am 08.01.2017 um 17:04 schrieb Paul A. Rubin :
> 
> On 01/07/2017 11:03 PM, Pavel Sanda wrote:
>> My understanding of your issue was that suddenly you were left without _any_
>> pdf viewer. For this putting the new pdf viewer at the end of list should 
>> work
>> and I am happy to fix that.
> You are right about my not having any viewer, but that was in part because I 
> had just done a system upgrade (which is what caused evince, gedit and the 
> previous image viewer to be replaced by the X-Apps) and had not yet gotten 
> around to reinstalling other programs that were deleted during the upgrade.
>> I don't feel like entering discussion what 'typical user' wants and start
>> messing up with order of viewers/editors.
>> While I see what you are saying about image viewer/text editor I don't see
>> how that "earns"
>> xreader > 'gv', 'ghostview -swap', 'gsview64', 'gsview32'
>> xreader > 'kghostview', 'xpdf', 'SumatraPDF', 'acrobat', 'acroread', 'mupdf'
>> xreader > 'kdvi', 'okular', 'yap', 'dviout -Set=!m'
>> for people out of your distro.
>> 
> At this point (having reloaded some programs), if I were to put the X-Apps at 
> the end of their respective vectors and reconfigure LyX, none of the X-Apps 
> would be selected. My default text editor would be notepad, which would 
> require running the Wine emulator. My default PDF viewer would be Acrobat 
> Reader (which would be okay with me). My default image viewer would be gimp, 
> which I find much too cumbersome just for looking at an image. So I would end 
> up having to edit the viewers in Tools > Preferences, which is exactly what I 
> would be doing with the previous configuration script.
> 
> Putting the X-Apps last in their respective vectors helps anyone who has none 
> of the other tools installed, so it's certainly better than nothing. I can 
> understand your being concerned about users suddenly finding a different 
> viewer than what they previously had, but my understanding is that the X-Apps 
> are direct substitutes for evince, gedit and (I think) xv, so it makes sense 
> to me that their precedence in the list would match the precedence assigned 
> to the apps they're replacing.

What about adding xdg-open instead to the list of PDF-viewers. This should do 
the right thing on every distro, IMO.

Stephan

Re: LyX 2.2 slowness

[Stephan Witt]

Am 31.12.2016 um 13:16 schrieb Jean-Marc Lasgouttes :
> 
> Le 16/12/2016 à 16:42, Jean-Marc Lasgouttes a écrit :
>> I'd be interested to see other tests, especially on MacOS and Windows.
> 
> Since there not much testing going on, I pushed the patch to master :) 
> Notable differences are:
> * the caching of getLayout is disabled with Qt5
> * the profiling hooks are kept, but profiling is disabled by default
> 
> I am still interested in reports on Mac and Windows

I tried the current master (commit 21259b66b5d36913aaf4dcded8aaac3254b04354) on 
Mac.
It seems to be fast with Qt5 - but I’m not sure how to verify that.

One thing I’ve noticed: the images in text are not shown immediately when 
scrolling
through the users guide. I didn’t investigate if the mentioned patch is causing 
this.
To make them appear one has to click in the main area or scroll again after 
stop.

Stephan 

Re: UserGuide.lyx lyx2lyx error "unusual contents found"

[Scott Kostyshak]

On Sun, Jan 08, 2017 at 04:38:12PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, den 08.01.2017, 10:24 -0500 schrieb Scott Kostyshak:
> > OK then I guess we should invert the tests (and perhaps continue the
> > debate in a bug report). The other possibility is the change the
> > regex
> > that checks for lyx2lyx errors to ignore these ones but that doesn't
> > seem like a good idea.
> 
> I can try to fix this at the lyx2lyx level once I am out of the
> biblatex tunnel.

OK.

Scott


signature.asc
Description: PGP signature

Re: Fwd: X-Apps

[Paul A. Rubin]

On 01/07/2017 11:03 PM, Pavel Sanda wrote:

My understanding of your issue was that suddenly you were left without _any_
pdf viewer. For this putting the new pdf viewer at the end of list should work
and I am happy to fix that.
You are right about my not having any viewer, but that was in part 
because I had just done a system upgrade (which is what caused evince, 
gedit and the previous image viewer to be replaced by the X-Apps) and 
had not yet gotten around to reinstalling other programs that were 
deleted during the upgrade.

I don't feel like entering discussion what 'typical user' wants and start
messing up with order of viewers/editors.
While I see what you are saying about image viewer/text editor I don't see
how that "earns"
xreader > 'gv', 'ghostview -swap', 'gsview64', 'gsview32'
xreader > 'kghostview', 'xpdf', 'SumatraPDF', 'acrobat', 'acroread', 'mupdf'
xreader > 'kdvi', 'okular', 'yap', 'dviout -Set=!m'
for people out of your distro.

At this point (having reloaded some programs), if I were to put the 
X-Apps at the end of their respective vectors and reconfigure LyX, none 
of the X-Apps would be selected. My default text editor would be 
notepad, which would require running the Wine emulator. My default PDF 
viewer would be Acrobat Reader (which would be okay with me). My default 
image viewer would be gimp, which I find much too cumbersome just for 
looking at an image. So I would end up having to edit the viewers in 
Tools > Preferences, which is exactly what I would be doing with the 
previous configuration script.


Putting the X-Apps last in their respective vectors helps anyone who has 
none of the other tools installed, so it's certainly better than 
nothing. I can understand your being concerned about users suddenly 
finding a different viewer than what they previously had, but my 
understanding is that the X-Apps are direct substitutes for evince, 
gedit and (I think) xv, so it makes sense to me that their precedence in 
the list would match the precedence assigned to the apps they're replacing.


Paul

Re: Biblatex

[Andrew Parsloe]

On 9/01/2017 7:50 a.m., Richard Heck wrote:


Thanks so much for doing this. I've not yet moved to biblatex myself,
but this will encourage me to give it a try.

Richard


On 01/08/2017 04:14 AM, Jürgen Spitzmüller wrote:

Biblatex support is ready over at the features/biblatex2 branch.

Of course we do not support the whole range of biblatex's feature set
natively, but we already support all that natbib/jurabib does and
substially more (features I'd like to add eventually include
refsection/refsegements and particularly so-called "qualified citation
lists").

Essentially, the current implementation introduces:

* Scanning and detection of the relevant files (package, styles)

* A GUI to
   - select biblatex engine(s) next to basic, jurabib, natbib,
   - set bibliography and citation style files (with default proposals)
   - set further biblatex package options (this field will later be also
 used by natbib and jurabib, an old request)
   - set options to the \printbibliography command

* Automatic setting of backend option if bibtex[8] is selected

* Style files that define biblatex's citation styles for the GUI and
xhtml output

* Make the BibTeX inset biblatex-aware (i.e., output \printbibliography
and optional argument in the body and pass the bib files to
\addbibresource macros in the preamble)

Along the way, I had to polish and extend our biblio-related code at
many places in order to enable things. Consequently, nothing in the
code is longer hardcoded to bibtex, natbib or jurabib, but generalized
in a way that it can be adjusted in the respective style files to the
needs of the respective engine. I was able to replace some ad-hoc
additions for the sake of specific engines with general, transparent
and extensible code (while keeping the functionality). This also
allowed me to fix some bugs and implement some long-standing desiderata
(such as the display of uppercased names and full author lists in the
GUI), en passant.

I have put most energy into a design that enables portability between
the diverse citation engines as much as possible, so it should be very
easy to switch an existing document from, say, natbib to biblatex and
(to a limited degree, since the feature set is larger) back. This is
why the citation styles use a common set of cmd names rather than just
the corresponding latex name.

If you want to try and play with it, check out the features/biblatex2
branch (not the old features/biblatex branch).

I propose to merge this to master rather soon, to give it more testing
and iron out potential bugs.

Jürgen


Given the age of this enhancement request and the number of people over 
the years who have enquired about biblatex support in LyX, I wonder if 
any thought has been given to its release? It feels more like the 
centrepiece of an accelerated 2.3 release than "tucked away" in a 2.2.x 
release.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: X-Apps

[Richard Heck]

On 01/08/2017 12:29 PM, Paul A. Rubin wrote:
> On 01/08/2017 11:51 AM, Stephan Witt wrote:
>> Am 08.01.2017 um 17:04 schrieb Paul A. Rubin :
>>>
>>> At this point (having reloaded some programs), if I were to put the
>>> X-Apps at the end of their respective vectors and reconfigure LyX,
>>> none of the X-Apps would be selected. My default text editor would
>>> be notepad, which would require running the Wine emulator. My
>>> default PDF viewer would be Acrobat Reader (which would be okay with
>>> me). My default image viewer would be gimp, which I find much too
>>> cumbersome just for looking at an image. So I would end up having to
>>> edit the viewers in Tools > Preferences, which is exactly what I
>>> would be doing with the previous configuration script.
>>>
>>> Putting the X-Apps last in their respective vectors helps anyone who
>>> has none of the other tools installed, so it's certainly better than
>>> nothing. I can understand your being concerned about users suddenly
>>> finding a different viewer than what they previously had, but my
>>> understanding is that the X-Apps are direct substitutes for evince,
>>> gedit and (I think) xv, so it makes sense to me that their
>>> precedence in the list would match the precedence assigned to the
>>> apps they're replacing.
>> What about adding xdg-open instead to the list of PDF-viewers. This
>> should do the right thing on every distro, IMO.
>>
>> Stephan
>
> That would definitely work for me, provided that xdg-open was first
> rather than last on each list. Since it uses the system default
> applications, it seems to me it belongs at the start of the lists.

Pavel will probably explain why we keep deciding not to do this. I can't
remember.

Richard

Re: LyX 2.2 slowness

[Stephan Witt]

Am 08.01.2017 um 18:42 schrieb Jean-Marc Lasgouttes :
> 
> Le 08/01/2017 à 18:00, Stephan Witt a écrit :
>> I tried the current master (commit 21259b66b5d36913aaf4dcded8aaac3254b04354) 
>> on Mac.
>> It seems to be fast with Qt5 - but I’m not sure how to verify that.
>> 
>> One thing I’ve noticed: the images in text are not shown immediately when 
>> scrolling
>> through the users guide. I didn’t investigate if the mentioned patch is 
>> causing this.
>> To make them appear one has to click in the main area or scroll again after 
>> stop.
> 
> I would be surprised that it is this particular patch, but this is definitely 
> something we need to fix.
> 
> JMarc
> 

Ok, I don’t see this with current 2.2.x. AFAIK, you did the backport and 
applied it there too.
The patch seems to be innocent :)

Stephan

Re: LyX 2.2 slowness

[Jean-Marc Lasgouttes]

Le 08/01/2017 à 18:59, Stephan Witt a écrit :

Ok, I don’t see this with current 2.2.x. AFAIK, you did the backport and 
applied it there too.
The patch seems to be innocent :)


A bisect would be appreciated :) Note that I have noticed problems with 
math previews not updating in master, I do not know whether this is related.


JMarc

Re: Testing of the 2.2.x Branch (esp Slowness)

[Richard Heck]

On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
>
>> The only thing I noticed is a
>> lot of messages
>>
>> QFile::remove: Empty or null file name
>>
>> in the calling shell window.
> We noticed the same thing at
> https://www.mail-archive.com/search?l=mid=a15e9a60-11bb-c081-84cb-9b7f8536b163%40free.fr
>
> but I could not figure out the root cause.

This must be coming from a call to QFile::remove in FileName.cpp. My
suggestion would be to put some LYXERR0 messages before each of them and
see where it's coming from. Then, once you know that, maybe put a
temporary assertion on a non-empty filename. Or even just start with that.

Richard

Re: [LyX features/biblatex2] Biblatex support

[Richard Heck]

On 01/08/2017 04:13 AM, Juergen Spitzmueller wrote:
> The branch, biblatex2, has been updated.
>
> - Log -
>
> commit 8319b3e9d615adc6b4b49a67308884400d20373f
> Author: Juergen Spitzmueller 
> Date:   Sun Jan 8 09:39:46 2017 +0100
>
> Biblatex support
> 
> File format change
>
> diff --git a/lib/citeengines/basic.citeengine 
> b/lib/citeengines/basic.citeengine
> index f8d5c5b..ae4a603 100644
> --- a/lib/citeengines/basic.citeengine
> +++ b/lib/citeengines/basic.citeengine
> @@ -3,7 +3,7 @@
>  #   The basic citation capabilities provided by BibTeX.
>  #   Mainly simple numeric styles primarily suitable for science and maths.
>  # DescriptionEnd
> -# Excludes: jurabib | natbib | biblatex
> +# Excludes: jurabib | natbib | biblatex | biblatex-natbib

Is it actually possible to choose more than one of these? If not, these
exclusion lines could be dropped altogether.

Richard

Re: Testing of the 2.2.x Branch (esp Slowness)

[Richard Heck]

On 01/08/2017 02:05 PM, Enrico Forestieri wrote:
> On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
>
>> On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
>>> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
>>>
 The only thing I noticed is a
 lot of messages

 QFile::remove: Empty or null file name

 in the calling shell window.
>>> We noticed the same thing at
>>> https://www.mail-archive.com/search?l=mid=a15e9a60-11bb-c081-84cb-9b7f8536b163%40free.fr
>>>
>>> but I could not figure out the root cause.
>> This must be coming from a call to QFile::remove in FileName.cpp. My
>> suggestion would be to put some LYXERR0 messages before each of them and
>> see where it's coming from. Then, once you know that, maybe put a
>> temporary assertion on a non-empty filename. Or even just start with that.
> Simply don't try to remove a file that has yet to be created. This occurs
> when cloning InsetExternal. See attached.

Looks reasonable enough to me. Seems to be in both master and stable.

Richard

Re: public identifier for DocBook XML export + unescaped '&' in

[Richard Heck]

On 01/07/2017 06:55 PM, Martin A. Brown wrote:
> Richard,
>
>>> I have used LyX on and off for many years and, working 
>>> sporadically with TLDP [0], I have handled a few documents that 
>>> were written in LyX.  Thank you to the LyX team for your work on 
>>> this tool over the years.
>>>
>>> I have two questions today, after examining the DocBook XML 
>>> output from the 2.2.x series.
>>>
>>> Question 1
>>> --
>>> Is it possible to change the public identifier for the DocBook 
>>> XML 4.2 output processor to use:
>>>
>>>   -//OASIS//DTD DocBook XML V4.2//EN   # -- my suggestion
>>>   -//OASIS//DTD DocBook XML//EN# -- current identifier [1]
>>>
>>> I have checked the XML catalogs on several different platforms 
>>> and I cannot find a reference to the latter identifier, and I 
>>> think it may simply be an oversight.  The system identifier (the 
>>> URL [2]) is correct.
>> This code goes way, way back to 2004. It seems to have been 
>> introduced at 33243f700. It appears that the one without "V4.2" was 
>> meant to be for XML, whereas the other one was meant to be for 
>> SGML. It's easy enough to change it so we output the same thing 
>> both times, but let me cc José and see if he has any thoughts.
> OK, great!  And thank you for the quick reply!
>
> The SGML public identifier (on line 2032) is correct.
>
>   -//OASIS//DTD DocBook V4.2//EN # -- for DocBook SGML at V4.2
>   -//OASIS//DTD DocBook XML V4.2//EN # -- for DocBook XML at V4.2
>
>>> Question 2
>>> --
>>> When running the DocBook XML export function, I discover that not 
>>> all text with '&' is not getting properly escaped with the XML 
>>> entity .  There's clearly code to handle that:
>>>
>>>   http://www.lyx.org/trac/browser/lyxgit/src/sgml.cpp#L46
>>>
>>> To the best of my ability I traced down a case of a Hyperlink 
>>> whose text is not properly XML-escaped.  I think this is the 
>>> line, but I'm not certain:
>>>
>>>   http://www.lyx.org/trac/browser/lyxgit/src/insets/InsetHyperlink.cpp#L235
>>>
>>>   int InsetHyperlink::docbook(odocstream & os, OutputParams const &) const
>>>   {
>>>   os << ">>  << subst(getParam("target"), from_ascii("&"), 
>>> from_ascii(""))
>>>  << "\">"
>>>  << getParam("name")
>>>  << "";
>>>   return 0;
>>>   }
>>>
>>> I think that getParam("name") also needs to be run through 
>>> sgml::escapeString.
>> Yes, that seems right. Since you have the git repo, can you make 
>> this change and test it? I'm not sure anyone on the development 
>> team actually uses the docbook classes.
> Yes, I can and I yes it works.  I have attached the patch.  I have never 
> touched C++ before, so this is just the dumbest thing I could suggest, though 
> it seems to do the trick.

Thanks, I've committed these. They're sufficiently minor that we don't
really NEED a license agreement, but if you'd like to be added to the
LyX credits (especially if we're going to have you help us clean up the
DocBook export), just send a message to this list saying something like:
"I hereby license my contributions to LyX under the General Public
License, version 2 or any later version."

Richard

Re: Biblatex

[Richard Heck]

Thanks so much for doing this. I've not yet moved to biblatex myself,
but this will encourage me to give it a try.

Richard


On 01/08/2017 04:14 AM, Jürgen Spitzmüller wrote:
> Biblatex support is ready over at the features/biblatex2 branch.
>
> Of course we do not support the whole range of biblatex's feature set
> natively, but we already support all that natbib/jurabib does and
> substially more (features I'd like to add eventually include
> refsection/refsegements and particularly so-called "qualified citation
> lists").
>
> Essentially, the current implementation introduces:
>
> * Scanning and detection of the relevant files (package, styles)
>
> * A GUI to
>   - select biblatex engine(s) next to basic, jurabib, natbib,
>   - set bibliography and citation style files (with default proposals)
>   - set further biblatex package options (this field will later be also
> used by natbib and jurabib, an old request)
>   - set options to the \printbibliography command
>
> * Automatic setting of backend option if bibtex[8] is selected
>
> * Style files that define biblatex's citation styles for the GUI and
> xhtml output
>
> * Make the BibTeX inset biblatex-aware (i.e., output \printbibliography
> and optional argument in the body and pass the bib files to
> \addbibresource macros in the preamble)
>
> Along the way, I had to polish and extend our biblio-related code at
> many places in order to enable things. Consequently, nothing in the
> code is longer hardcoded to bibtex, natbib or jurabib, but generalized
> in a way that it can be adjusted in the respective style files to the
> needs of the respective engine. I was able to replace some ad-hoc
> additions for the sake of specific engines with general, transparent
> and extensible code (while keeping the functionality). This also
> allowed me to fix some bugs and implement some long-standing desiderata
> (such as the display of uppercased names and full author lists in the
> GUI), en passant.
>
> I have put most energy into a design that enables portability between
> the diverse citation engines as much as possible, so it should be very
> easy to switch an existing document from, say, natbib to biblatex and
> (to a limited degree, since the feature set is larger) back. This is
> why the citation styles use a common set of cmd names rather than just
> the corresponding latex name.
>
> If you want to try and play with it, check out the features/biblatex2
> branch (not the old features/biblatex branch).
>
> I propose to merge this to master rather soon, to give it more testing
> and iron out potential bugs.
>
> Jürgen

Re: Testing of the 2.2.x Branch (esp Slowness)

[Enrico Forestieri]

On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:

> On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> > On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
> >
> >> The only thing I noticed is a
> >> lot of messages
> >>
> >> QFile::remove: Empty or null file name
> >>
> >> in the calling shell window.
> > We noticed the same thing at
> > https://www.mail-archive.com/search?l=mid=a15e9a60-11bb-c081-84cb-9b7f8536b163%40free.fr
> >
> > but I could not figure out the root cause.
> 
> This must be coming from a call to QFile::remove in FileName.cpp. My
> suggestion would be to put some LYXERR0 messages before each of them and
> see where it's coming from. Then, once you know that, maybe put a
> temporary assertion on a non-empty filename. Or even just start with that.

Simply don't try to remove a file that has yet to be created. This occurs
when cloning InsetExternal. See attached.

-- 
Enrico
diff --git a/src/insets/InsetExternal.cpp b/src/insets/InsetExternal.cpp
index b68a09d..00c304a 100644
--- a/src/insets/InsetExternal.cpp
+++ b/src/insets/InsetExternal.cpp
@@ -99,7 +99,8 @@ TempName::~TempName()
 TempName & TempName::operator=(TempName const & other)
 {
if (this != ) {
-   tempname_.removeFile();
+   if (!tempname_.empty())
+   tempname_.removeFile();
support::TempFile f("lyxextXX.tmp");
f.setAutoRemove(false);
tempname_ = f.name(); 

Re: Testing of the 2.2.x Branch (esp Slowness)

[Enrico Forestieri]

On Sun, Jan 08, 2017 at 03:14:51PM -0500, Richard Heck wrote:
> On 01/08/2017 02:05 PM, Enrico Forestieri wrote:
> > On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
> >
> >> On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> >>> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
> >>>
>  The only thing I noticed is a
>  lot of messages
> 
>  QFile::remove: Empty or null file name
> 
>  in the calling shell window.
> >>> We noticed the same thing at
> >>> https://www.mail-archive.com/search?l=mid=a15e9a60-11bb-c081-84cb-9b7f8536b163%40free.fr
> >>>
> >>> but I could not figure out the root cause.
> >> This must be coming from a call to QFile::remove in FileName.cpp. My
> >> suggestion would be to put some LYXERR0 messages before each of them and
> >> see where it's coming from. Then, once you know that, maybe put a
> >> temporary assertion on a non-empty filename. Or even just start with that.
> > Simply don't try to remove a file that has yet to be created. This occurs
> > when cloning InsetExternal. See attached.
> 
> Looks reasonable enough to me. Seems to be in both master and stable.

Committed at 25e6b5da. Please, cherry pick if you want it in stable.

-- 
Enrico

Re: public identifier for DocBook XML export + unescaped '&' in

[Martin A. Brown]

Hello,

>> Yes, I can and I yes it works.  I have attached the patch.  I 
>> have never touched C++ before, so this is just the dumbest thing 
>> I could suggest, though it seems to do the trick.
>
>Thanks, I've committed these. They're sufficiently minor that we 
>don't really NEED a license agreement, but if you'd like to be 
>added to the LyX credits (especially if we're going to have you 
>help us clean up the DocBook export), just send a message to this 
>list saying something like: "I hereby license my contributions to 
>LyX under the General Public License, version 2 or any later 
>version."

For my contributions to LyX, I hereby license my contributions to 
LyX under the General Public License, version 2 or any later 
version.

-Martin

P.S.  Thanks for the direction on that, Richard.

-- 
Martin A. Brown
http://linux-ip.net/

Re: Testing of the 2.2.x Branch (esp Slowness)

[Richard Heck]

On 01/08/2017 05:22 PM, Enrico Forestieri wrote:
> On Sun, Jan 08, 2017 at 03:14:51PM -0500, Richard Heck wrote:
>> On 01/08/2017 02:05 PM, Enrico Forestieri wrote:
>>> On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
>>>
 On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
>
>> The only thing I noticed is a
>> lot of messages
>>
>> QFile::remove: Empty or null file name
>>
>> in the calling shell window.
> We noticed the same thing at
> https://www.mail-archive.com/search?l=mid=a15e9a60-11bb-c081-84cb-9b7f8536b163%40free.fr
>
> but I could not figure out the root cause.
 This must be coming from a call to QFile::remove in FileName.cpp. My
 suggestion would be to put some LYXERR0 messages before each of them and
 see where it's coming from. Then, once you know that, maybe put a
 temporary assertion on a non-empty filename. Or even just start with that.
>>> Simply don't try to remove a file that has yet to be created. This occurs
>>> when cloning InsetExternal. See attached.
>> Looks reasonable enough to me. Seems to be in both master and stable.
> Committed at 25e6b5da. Please, cherry pick if you want it in stable.

Thanks.

rh

Re: [LyX features/biblatex2] Biblatex support

[Jürgen Spitzmüller]

Am Sonntag, den 08.01.2017, 13:55 -0500 schrieb Richard Heck:
> > -# Excludes: jurabib | natbib | biblatex
> > +# Excludes: jurabib | natbib | biblatex | biblatex-natbib
> 
> Is it actually possible to choose more than one of these? If not,
> these
> exclusion lines could be dropped altogether.

You're right, it does not make sense at all. It's a relict from the
module heritage. I'll remove the lines and also the respective code.

Excluding modules might make sense, but that can be done with
ExcludesModule.

Thanks
Jürgen

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