Re: 2.2 (was: Re: Retina support)
On Fri, Jan 9, 2015 at 2:43 PM, Liviu Andronic wrote: > On Tue, Jan 6, 2015 at 7:58 PM, Jean-Marc Lasgouttes > wrote: > > As far as I am concerned, I'd just like to land the scroll-reloaded > branch > > ASAP. It will not improve any more without testing. > > > > Who has plans for 2.2 that have not been executed yet? > > > What about the other GSoC projects? What are their status, and is > their any chance that they could make it into 2.2? > > Below's the list of pending GSoC code, and principal mentors (from memory). > 2014: > - Round trip conversion between LyX and .docx formats (Stefano) > - Interactive LyX (Tommaso) > > 2013: > - Horizontal scrollbar (JMarc, and I suspect that this is the > 'str-metrics' branch) > - XHTML and ePub support (Richard) > - UI Improvement and support for Non-Linear Writing (Rob) > > Sorry for dropping off the radar---I have been going through some medical issues since the beginning of the year. I hope to integrate the lyx/odt Gsoc work into a future version, not sure it will be 2.2. I haven't really worked on the code since last Fall. Status: LyX-->ODT is almost complete, with the exception of the font/multiscript issue that would require an external lua module for luatex. ODT--> LyX is basically at the "proof of concept" stage Cheers, Stefano -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Pushing to features branch(es)?
Is there any special magic I am supposed to use to push a commit on features/biblatex upstream? [stefano@gorgias]$ git status On branch features/biblatex Your branch is ahead of 'master' by 1 commit. (use "git push" to publish your local commits) [stefano@gorgias]$ git push Everything up-to-date ??? What am I doing wrong? S. -- __________ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Python 3 incompatibilities still exist right?
On Thu, Nov 20, 2014 at 11:36 AM, Richard Heck wrote: > On 11/20/2014 09:55 AM, stefano franchi wrote: > > On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak wrote: > >> I cleaned RELEASE-NOTES for the master branch. This note is still >> relevant right? >> >> - LyX needs to be run under Python 2 and will not work properly on systems >> where Python 3 is the default binary. See bug #7030 to know how to fix >> this properly, since simple sheebang conversion in *.py files will not >> be enough. >> >> >> I've seen some references here and there (e.g. Benjamin's work on >> features/python3), but Python 3 incompatibility is still in master >> right? >> > > Actually, I thought this problem was solved a couple of years or so ago > (about Lyx? 2.0.2) > I used to have problems on my ArchLinux box (with python 3 as a default) > but that is no longer > the case. > > > There are two different issues here: (i) Will LyX work when Python 3 is > the default? (ii) Will > LyX work with Python 3? The answer to the former is "Yes", as long as > Python 2 is available: > We now look for it explicitly. The answer to the latter, I believe, is > "No": The LyX scripts will > not run under Python 3, though some work has been done on that, as Scott > mentioned. > > That's my experience on Linux. However, Alex seemed to suggest (i) is not completely true on Windows. If I understood his point correctly, LyX will work when python 3 is the default by installing its own python2 interpreter, which proceeds to break things (which things, I am not sure. Alex did not say). So perhaps there are three cases: (i) Will LyX work when Python 3 is the default, but Python 2 is available? (ii) Will LyX work with Python 3? (iii) Will LyX work when Python 3 is the default and LyX install its own version of Python? And he answers are yes, no, kind of? S. -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Python 3 incompatibilities still exist right?
On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak wrote: > I cleaned RELEASE-NOTES for the master branch. This note is still > relevant right? > > - LyX needs to be run under Python 2 and will not work properly on systems > where Python 3 is the default binary. See bug #7030 to know how to fix > this properly, since simple sheebang conversion in *.py files will not > be enough. > > > I've seen some references here and there (e.g. Benjamin's work on > features/python3), but Python 3 incompatibility is still in master > right? > Actually, I thought this problem was solved a couple of years or so ago (about Lyx? 2.0.2) I used to have problems on my ArchLinux box (with python 3 as a default) but that is no longer the case. Stefano -- __________ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Biblatex module--help on syntax welcome
On Mon, Nov 10, 2014 at 5:56 PM, Scott Kostyshak wrote: > On Mon, Nov 10, 2014 at 6:46 PM, stefano franchi > wrote: > > Dear all, > > > > Jurgen was not kidding when he said the syntax of the bib modules is > > somewhat crypticand the documentation is a bit sparse(;-)) > > > > So here are a few notes that may serve as a base for a fuller > documentation > > effort. Input greatly welcome, especially in the section marked as FIXME > > between dotted lines. > > Thanks for your work on this, Stefano! Once the documentation > develops, if you think something is too technical to go in the manuals > a good place might be lib/doc/Development. I would really like to see > that document grow and have plans to contribute myself, but haven't > done so yet. > > Thanks for the pointer Scott. I was unaware of that document. It seems indeed the perfect place to put a more technical description of the bib modules. Cheers, S. -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Biblatex module--help on syntax welcome
if-clause]][[else-clause]]}
if "fieldName" exists, it replaces it with "if-value," otherwise it
replaces it with "else-value".
4. !token {!!}
Replaces "token with "HtmlTag", but only in case of HTML output
-
FIXME: Where is it decided to output HTML instead of plain text?
-
5. __token translatedBit
Replaces "token" with the "translatedBit"
-
FIXME: I am really confused about this clause form:
First, because the documentation says it is not a macro, even though there
is a substitution going on.
Second, they are called "translatable bits", but who does the translation?
In other words, if I want a biblatex module for language X, do I write a
new BibLatex-X.module with the various strings in language X (and in it it,
I perhaps simply import the bibtlatex.module and redefine the
translations? Or are the translations stored somewhere else, and indexed
accordingly?
---------
Thanks for the help.
Cheers,
Stefano
--
__
Stefano Franchi
stefano.fran...@gmail.com
http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
On Sun, Nov 9, 2014 at 2:12 PM, Richard Heck wrote: > On 11/09/2014 10:35 AM, stefano franchi wrote: > > > > On Sun, Nov 9, 2014 at 9:20 AM, Jürgen Spitzmüller wrote: > >> stefano franchi wrote: >> > Right. But if going for a change in the Document dialog, the Bibtex >> inset >> > would become overkill, wouldn't it? It'd be better to create a new and >> much >> > simpler inset. >> >> Why? You can attach a different dialog to it if biblatex is used. The >> advatage >> of using the existing inset is that people can switch existing documents >> from/to biblatex easily (without having to replace insets). >> >> The inset itself will output what is requested in either case. >> >> > > Not sure I get this, will get back to it when I understand the machinery > better. > > > Jurgen just means that the cite engine can be set in Document> Settings> > Bibliography as it is now, and then when someone clicks on the BibTeX inset > we can launch different dialogs depending upon which engine is in use. I'm > not totally sure how to do that right now, but we can figure it out. > Ah, ok, thanks for clarifying. I had thought Jurgen meant a full-blown biblatex panel could be accessible (only) from the document settings panel (i.e. Dmitri's suggestion). > > I am starting to take a look at the full set of biblatex's citing > commands for the biblatex module, and it's overwhelming to say the least. > Will need to aim low, at least at the beginning. Some of the commands may > not be implementable with the current machinery, I am afraid (e.g. the low > level commands that pick a specified field from a bibtex ref), or may be > very tricky to render the LyX way (i.e. the autocite commands). > Will keep investigating. > > > I'd start by implmenting the basics. We don't necessarily have to provide > everything biblatex does at the very beginning. There is always ERT. > Agreed. > > I also wouldn't worry at the moment about support for files other than > bibtex. Doing that will require writing (or finding) a parser of some sort > for those other files that will do what InsetBibtex::parseBibTeXFiles() > does for those. > Biblatex/biber now support bibtex, Ris, Zotero, and Endnote XML, with the last three formats' support being marked as "experimental" (version 2.9a of June 2014). Since it is biber that actually parses those formats, it may be possible to leverage biber itself from within LyX. At any rate, I fully agree it is a premature question. Cheers, S. -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
On Sat, Nov 8, 2014 at 5:15 AM, dd3fmlli wrote: > > as a biblatex user, I would like to add a (probably marginal) comment on > the list of the desired features. > > One of the most interesting features of biblatex, for me, is the fact > that "database" is detached from the actual printing command. Namely, once > one adds a "bib" file to the document with the command \bibliography, it > is possible to print also several different bibliographies e.g. one per > section or one with only books and one with only articles. This can be done > just adding several times the command \printbibliography with the > appropriate arguments. > > My suggestion would be to use two different dialogs, one for the database > (as suggested) and one for the \printbibliography command. This would also > reduce the number of possible options in each dialog. > > A possibility can be to set \printbibliography by default from the > database dialog, as suggested by Stefano, and introduce another command > e.g. in Insert-> Bibliography->PrintBibliography to add further > bibliographies in the text, but I think that detaching completely the two > commands is more "in the spirit" of biblatex package. One could also keep > the bibtex dialog, enriching it with biblatex features (as far as I know it > is impossible to use both biblatex and bibtex in the same document). > > I agree that your proposed solution would be more in the spirit of biblatex: putting all the loading and configuring commands in the preamble and using \printbibliography commands in the text. That would mean adding a biblatex pane to the Document settings panel, I guess (or somehow modyfying the existing Bibliorgaphy panel in the settings to optionally include biblatex info). And creating a Biblatex inset that simply puts the printing bibliography commands in the text. > Thank you for proposing the bilblatex support, I am really happy if this > project starts, and I would be glad to help. I can program in C++, but I've > never used qt. However, I'd like to learn it. > > Thanks for the help. It may start soon, but will proceed very slowly, as I have to become proficient in C++ along the way. Cheers, Stefano -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
On Sun, Nov 9, 2014 at 9:21 AM, Jürgen Spitzmüller wrote: > Am Sonntag 09 November 2014, 08:31:10 schrieb stefano franchi: > > So, before I start playing with the code: what's the recommended git > usage > > in this case? Should I create a biblatex branch in the features repo (as > > described in the wiki)? Or should I simply create a personal repo for the > > moment? > > > > Stefano > > I'd go for the former. > > Well, I tried to, but it seems I do not have writing permission on the features repo >git push --set-upstream features master:biblatex produces: W access for features DENIED to stefano (Or there may be no repository at the given path. Did you spell it correctly?) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. S. -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
On Sun, Nov 9, 2014 at 9:20 AM, Jürgen Spitzmüller wrote: > stefano franchi wrote: > > Right. But if going for a change in the Document dialog, the Bibtex inset > > would become overkill, wouldn't it? It'd be better to create a new and > much > > simpler inset. > > Why? You can attach a different dialog to it if biblatex is used. The > advatage > of using the existing inset is that people can switch existing documents > from/to biblatex easily (without having to replace insets). > > The inset itself will output what is requested in either case. > > Not sure I get this, will get back to it when I understand the machinery better. I am starting to take a look at the full set of biblatex's citing commands for the biblatex module, and it's overwhelming to say the least. Will need to aim low, at least at the beginning. Some of the commands may not be implementable with the current machinery, I am afraid (e.g. the low level commands that pick a specified field from a bibtex ref), or may be very tricky to render the LyX way (i.e. the autocite commands). Will keep investigating. S. -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
So, before I start playing with the code: what's the recommended git usage in this case? Should I create a biblatex branch in the features repo (as described in the wiki)? Or should I simply create a personal repo for the moment? Stefano -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
On Sun, Nov 9, 2014 at 3:06 AM, Jürgen Spitzmüller wrote: > stefano franchi wrote: > > From a user's perspective, a minimally satisfactory support of biblatex > > requires the following: > > > > 1. A biblatex dialog similar to the current bibtex's dialog, where users > > can enter: > > a. the list of files (not necessarily in bibtex format) containing > the > > references > > b. the citation style to be used in-text > > c. the reference style to be used in the references section > > d. a list of additional biblatex's specific calling parameters > > Extend the existing bibliography pane of the document dialog, > Right, that would also go in Dmitiri's direction. And it may actually be simpler to do. > > > 2. A mechanism to insert citations in the text that takes advantage of > > biblatex's more extensive set of citation commands (e.g. citeauthor, > > citetitle, etc.) > > This is actually already in place. See the modules basic.module, > natbib.module > and jurabib.module. Create a biblatex.module which adds the necessary > styles > and macro. (The syntax of these modules is a bit exotic, to put it mildly, > but > you will get used to it). > > Good. The overall scheme is getting clearer. I may actually start from the module, as it seems to be the easiest point of attack. Also, you need to > > 3. Modify the bibtex inset and its dialog for \printbibliography. > > Right. But if going for a change in the Document dialog, the Bibtex inset would become overkill, wouldn't it? It'd be better to create a new and much simpler inset. > I am a bit short of time ATM, but I try to help where I can. > > Thanks, S. -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Toward Biblatex support: understanding what work is required
On Sat, Nov 8, 2014 at 4:53 PM, Richard Heck wrote: On 11/04/2014 01:21 PM, stefano franchi wrote: > >> b. I don't quite understand where and how the widget itself is defined. >> I am used to either define widget programmatically by creating (and >> possibly nesting) layouts and then adding the widgets manually, or by >> creating them by hand with QT Designer and then importing them into code. I >> can't see either method used here. My ignorance of C++ is certainly to >> blame and input would be welcome. >> > > It's done the Qt Designer way. The designer file is at > src/frontends/qt4/ui/BibtexUi.ui. You'll see it imported into GuiBibtex.h > via: > #include "ui_BibtexUi.h" > That header file is produced by the Qt MOC (meta-object compiler) on > compilation. > > Thanks Richard, I had missed that. > I still have no clear idea of: >> >> c. where and how is the bibtex widget called. >> > > Do you mean how it pops up? There is a createGuiBibtex() routine in > GuiBibtex.cpp that is called from GuiView::build(). I think it is enough to > add one of those to the "factory". > I meant the latter. Clear now. > > There are actually two very different dialog systems in existence right > now. Don't ask. ;-) > > d. where is the machinery that's needed to insert citations into LyX. >> Is it the src/insets/InsetBibtex.cpp class? (of which I confess I >> have a very >> dim understanding)? >> > > Citations themselves are inserted through GuiCitation. > Ok > > Note, by the way, that the Gui* classes interact with corresponding Inset* > classes. So GuiBibtex manages InsetBibtex, in effect. Etc. You'll need an > InsetBiblatex (say) as well as GuiBiblatex. > > e. how the various cite commands are inserted in the insert inset pop-up >> list. >> > > This happens in GuiCitation, again. Though the citations styles themselves > are all defined in modules corresponding to the different cite engines: > basic.module, natbib.module, jurabib.module. This will be a big help, since > the cite styles won't need to be hardcoded. It can all be put in modules. > Presumably, we will need to figure out whatt the available modules are at > load time and then use that to populate the list of choices. I'm not sure > exactly how this part will work, but we can figure it out as we go. We'll > also need somehow to be able to tell what reference styles are available, > though if there is no easy way to do that, we can just make the user enter > one as text. > > Ok, clearer now. So, ui files aside, the three main C++ classes managing bibtex are GuiBibtex+InsetBibtex and GuiCitation. The latter wouldn't need to be touched, for the citation formats are taken care by modules. > About the above: The reference files don't have to be in bibtex format? > Yes, since a few versions ago biber supports several bibliograpic file formats. Endnote and Bibtex for sure, plus possibly other. Which is why you are no longer allowed to use the .bib extension in biblatex "addbibresource" command. Stefano -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Toward Biblatex support: understanding what work is required
Dear devels, I am starting to look into biblatex support, with a long term project of perhaps writing the required code or (what's more likely, given my poor knowledge of C++) helping put together some general desiderata and detailing the associated work. My understanding of the problem is the following: >From a user's perspective, a minimally satisfactory support of biblatex requires the following: 1. A biblatex dialog similar to the current bibtex's dialog, where users can enter: a. the list of files (not necessarily in bibtex format) containing the references b. the citation style to be used in-text c. the reference style to be used in the references section d. a list of additional biblatex's specific calling parameters This dialog box would insert in the document's preamble a call to biblatex (with the parameters at (d) passed verbatim) plus a series of \addbibresource commands (one per reference file) Additionally, it would insert a \printbibliography command at the cursor location (when it was opened), similarly to the current bibtex's dialog 2. A mechanism to insert citations in the text that takes advantage of biblatex's more extensive set of citation commands (e.g. citeauthor, citetitle, etc.) 1+2 would mimick LyX-bibtex's current behavior for biblatex. A natural way to approach the biblatex issue would then be to replicate bibtex's machinery and change what's needed Now, as a question to the developers: where is the magic for 1 and 2 happening in LyX's codebase (for bibtex, I mean)? Warning: I am somewhat familiar with Qt 4, but only as used from python through pyqt. My knowledge of C++ is rudimentary as best---please be gentle! My fumbling search through the code has reached the following preliminary conclusions: a. frontends/qt4/GuiBibtex.cpp defines the Bibtex dialog's class with all the required signal/slot connections and associated methods. b. I don't quite understand where and how the widget itself is defined. I am used to either define widget programmatically by creating (and possibly nesting) layouts and then adding the widgets manually, or by creating them by hand with QT Designer and then importing them into code. I can't see either method used here. My ignorance of C++ is certainly to blame and input would be welcome. I still have no clear idea of: c. where and how is the bibtex widget called. d. where is the machinery that's needed to insert citations into LyX. Is it the src/insets/InsetBibtex.cpp class? (of which I confess I have a very dim understanding)? e. how the various cite commands are inserted in the insert inset pop-up list. Comments appreciated. Cheers, Stefano -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: biblatex native support
On Tue, Nov 4, 2014 at 2:58 AM, Jürgen Spitzmüller wrote: > 2014-11-03 18:52 GMT+01:00 PhilipPirrip: > >> I'm wondering what went wrong with GSoC 2014 promises for biblatex/LyX. >> > > Lack of manpower. > > Well, it was not only that. We did receive two Summer of Code of proposals for the Biblatex native support project, but both received very low scores from the developers. In other words, there was little confidence that either would succeed. If we go again for GSOC next year, we may have better luck. Stefano -- __________ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: Google Code-In 2014
On Tue, Oct 7, 2014 at 7:33 PM, Cyrille Artho wrote: > Dear all, > When discussing the need to support HiDPI displays, I brought up the idea > of joining Google Code-In. This is a much smaller version of GSoC, aimed at > high school students. Students complete small tasks and can get T-shirts > and other promotional items; the main part of the program runs from Dec. 1 > - Jan. 19 and has just been announced yesterday. > > We would have to register soon (registration of organizations begins on > Oct. 27 and ends on Nov. 12). The following tasks are eligible: > > 1.Code: Tasks related to writing or refactoring code > > 2.Documentation/Training: Tasks related to creating/editing documents > and helping others learn more > > 3.Outreach/Research Tasks related to community management, > outreach/marketing or studying problems and recommending solutions > > 4.Quality Assurance: Tasks related to testing and ensuring code is of > high quality > > 5.User Interface: Tasks related to user experience research or user > interface design and interaction > > It seems to be necessary to have at least five tasks of each type, with > over 50 tasks in total; this may be a challenge for us. Note that a task is > quite small, though, something that would take us 1 - 2 hours to carry out, > so a high school student should take 3 - 5 hours. > > Tasks should be independent of each other, and it may be difficult for us > to come up with 100+ tasks as requested. Also, translation tasks are not > eligible this year. > > In short, we would need at least two mentors of each category (to ensure a > fast turn-around even during holidays), and 5 - 30 tasks per category (by > Dec. 1). This seems like a daunting challenge. For coding tasks, we > probably have enough open things on the to-do lists (such as the feature > polls on the LyX wiki), but not so many of these may be feasible within two > hours. Note that "beginner tasks" can be used to help students familiarize > themselves with the code base, so some tasks may assume prior knowledge of > the LyX codebase. > > What do you think? To me it seems like a lot of people would have to get > involved to "scale up" to the numbers that Google expects here. Probably > large organizations can handle this more easily. Still, it is good to be > aware of this opportunity so we can at least consider it. > I can help with admin duties and possibly also mentoring on non C++ related tasks (including coming up with tasks). But I cannot do anything until the end of the month, as I will be traveling non-stop until then. That being said, I agree with Cyrille that Google's requirements seem like a big tasks for small orgs. Perhaps we'll get some enlightenment at the forthcoming Reunion. Cheers, S. > -- > Regards, > Cyrille Artho - http://artho.com/ > Nothing is more admirable than the fortitude with which > millionaires tolerate the disadvantages of their wealth. > -- Nero Wolfe > -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: new trac keyword gsoc?
On Sat, Oct 4, 2014 at 2:28 PM, Scott Kostyshak wrote: > Instead of waiting until two weeks before the GSOC deadline to come up > with ideas, would it make sense to have a trac keyword "gsoc" that > would mean "fixing this bug/feature might be a reasonable gsoc > project"? An alternative is to make a note on the gsoc wiki page, but > I think we are less likely to find that page and edit it than we are > to just write one word in the keywords box. > +1 -- __________ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: GSOC LyXToWordConversion
Hi Tariq, sorry for not getting back to you---I thought Prannoy's message had reached you. My mistake. On Fri, Sep 19, 2014 at 5:28 AM, tesm...@gmail.com wrote: > Did you manage to produce a single gsoc repository for testing purposes? > > Prannoy created a single repository called "prannoy" that contains all the work he did over the summer. It is one one the main branches in the gsoc repository: http://git.lyx.org/?p=gsoc.git;a=summary Let me know how your tests go. Cheers, Stefano -- __________ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: GSOC LyXToWordConversion
Hi Tariq, thanks for asking about the project. I am afraid it is not quite ready yet for public consumption. Prannoy put together some scripts that tie everything together, but all the code is still parked in the various gsoc repositories. I haven't had the time to look at it since the end of Google's summer of code because of a major professional deadline that's coming up this week. I hope to get back to the project next week and produce at the very least a single gsoc repo that could be easily cloned for testing purposes. Cheers, Stefano On Thu, Sep 4, 2014 at 4:29 AM, tesm...@gmail.com wrote: > Dear Stefano, > > I did not have any update from you regarding LyxToWordConversion. Is it > ready for use? > > Regards, > Tariq > > > On Thu, Aug 7, 2014 at 11:07 PM, stefano franchi < > stefano.fran...@gmail.com> wrote: > >> Hi Tariq, >> >> it is great to hear you are willing to test the work Prannoy did over the >> summer in the context of Google's summer of code. >> As Richard pointed out, the code (it's all in .4ht files) is in the gsoc >> repository, and more precisely in the tests directory. >> >> I would just ask you to wait a few more days, as Prannoy is now in the >> final week of the project and he is moving stuff around and testing a >> script that allows a the conversion to ODT to be launched directly from the >> LyX interface, thereby greatly simplifying the testing process. >> >> Bug me again in a week or so if you don't hear from me. >> >> Cheers, >> >> Stefano >> >> >> On Thu, Aug 7, 2014 at 2:00 PM, Richard Heck wrote: >> >>> On 08/06/2014 10:52 AM, tesm...@gmail.com wrote: >>> >>>> Dear Richard, >>>> >>>> Thanks for your reply. >>>> >>>> I would like to participate in testing of the GSOC project to >>>> LyxToWordConversion [http://wiki.lyx.org/GSoC/LyxToWordConversion]. >>>> >>>> Would someone please add me to the list and provide the binaries/code >>>> for testing? >>>> >>> >>> Communication about the project happens on this list. The code is in the >>> LyX GSOC repository, which you can browse here: >>> http://git.lyx.org/?p=gsoc.git;a=summary >>> I'm not sure which branches (listed at the bottom) are part of this >>> project, but presumably odt2lyx is one of them, as are the lyx2word >>> branches. >>> >>> I'm cc'ing the people mainly involved in this. They can give us more >>> info. >>> >>> Richard >>> >>> >> >> >> -- >> __ >> Stefano Franchi >> Associate Research Professor >> Department of Hispanic Studies Ph: +1 (979) 845-2125 >> Texas A&M University Fax: +1 (979) 845-6421 >> College Station, Texas, USA >> >> stef...@tamu.edu >> http://stefano.cleinias.org >> > > -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: [GSoC Mentors] After GSoC ... Semester of Code!
On Thu, Sep 4, 2014 at 8:35 AM, Liviu Andronic wrote: > On Thu, Sep 4, 2014 at 3:32 PM, Liviu Andronic > wrote: > > On Tue, Sep 2, 2014 at 9:59 AM, Jean-Marc Lasgouttes > wrote: > >>> So, mentors, would you be interested/available for this programme? If > >>> you would entertain this, now is the time to raise your hand. > >> > >> > >> Well, considering that the code from our first GSoC has not landed yet, > I > >> wonder whether we can handle all this load. > >> > >> OTOH, if we can have projects more akin to code cleanup (that are not > >> accepted by GSoC), they may be more directly useful. > >> > > I've been reading their FAQ and this came up: > > > > http://semesterofcode.com/?p=22 > > "Do Semester of Code projects have to involve writing code? > > > > Generally, student projects at our partner institutions involve > > programming, so projects with this focus will be most popular and > > relevant. However, projects involving other areas of software > > engineering are acceptable, including system design, quality > > evaluation, testing, documentation, translation etc. > > Guidelines for submitting project ideas will be provided when the idea > > submission period launches." > > > > So code-cleanup and similar tasks could be acceptable for this programme. > > > > > http://osswatch.jiscinvolve.org/wp/2014/08/06/vals-semester-of-code-open-for-project-idea-submissions/ > > "The project should take about 3 months to complete. Please bear in > > mind that it’s better to start with a smaller project that can be > > extended if your student proves to be capable rather than have an > > over-ambitious idea which can’t be completed in time." > > > > They seem to recommend smaller tasks rather than big, difficult projects. > > > Come to think of it, we might even ask the student to clean up the > GSoC code and complete the integration with LyX master. :) > > Liviu > > > > Some interesting differences from GSoC: > > - Students are not payed, but their work on the FOSS project counts > > towards academic credits. > > - In addition to the mentor and the student, there is also the > > academic supervisor (should simplify the mentor's task of keeping the > > student in check) > > - It seems to me that this programme is more focused on getting > > students tightly knit with the open-source community, rather than on a > > clear, biggish, well-defined feature. > > - The deadlines are flexible, and to be defined among > > mentor/student/academic supervisor. > > > > The deadline for our application is Sep 12th. If we have two willing > > mentors and some code clean-up ideas or a newish feature that would > > require less involvement from the mentor, then we still have the time > > to require at least one slot. I think it's worth a try. > > Agreed. I can help with the admin setup, but I can't be a mentor though. Cheers, Stefano -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: [GSoC Mentors] After GSoC ... Semester of Code!
I On Tue, Sep 2, 2014 at 2:59 AM, Jean-Marc Lasgouttes wrote: > Le 02/09/2014 09:39, Liviu Andronic a écrit : > > On Tue, Sep 2, 2014 at 9:15 AM, wrote: >> >>> Maybe something for LyX to participate? >>> >>> This sounds very interesting, and I guess Stefano and I could take >> care of the application paperwork (so to speak), but for the usual >> question on mentor availability. >> >> So, mentors, would you be interested/available for this programme? If >> you would entertain this, now is the time to raise your hand. >> > > Well, considering that the code from our first GSoC has not landed yet, I > wonder whether we can handle all this load. > > OTOH, if we can have projects more akin to code cleanup (that are not > accepted by GSoC), they may be more directly useful. > > Agreed. Speaking about the recently concluded GSOC, I think it will take quite some time to integrate the (overall positive) results into LyX. I'm willing to help out with admin duties, however, if there is some mentoring interest among the devs. Cheers, Stefano > JMarc > > -- __ Stefano Franchi stefano.fran...@gmail.com http://stefano.cleinias.org
Re: [LyX GSoC/odt2lyx] Updated Tests-Report.lyx and completed documenting parseodt.py which is the main script for ODT to LyX conversion
On Wed, Aug 20, 2014 at 8:11 AM, Prannoy Pilligundla wrote: > ᐧ > On Wed, Aug 20, 2014 at 12:00 AM, Scott Kostyshak > wrote: >> >> >>> The actual problem is because of the difference in ODT syntax that >>> tex4ht uses and that the latest versions of Libre Office or Open Office >>> uses. Suppose we just open the ODT generated by tex4ht, make a slight >>> change and save it there are large number of differences in all the xml >>> files before and after saving. So I guess it becomes difficult for us to >>> take an example file in these kind of cases and compare them. And as our >>> main aim was semanticity, even verifying semanticity becomes very difficult >>> to verify keeping in mind all these constraints. >>> >> >> Did you mean to email this to me and not the list? We try to keep things >> on the list as much as possible. >> > > Oh Sorry, just realized that I just mailed you and not the list. I wanted > to reply to all but maybe I clicked on reply by mistake. Again, I am sorry, > will be careful from next time on. > >> >> I think we're talking about different kinds of tests. The kind I have in >> mind are the following: suppose you make a change to the ODT export. How >> can you be sure that that change doesn't break anything? One way to address >> this is to have tests. You would not need to open Libre Office or in fact >> even have it installed. The tests would just check that nothing changed in >> the other exports (it would do this just like tex2lyx by comparing a saved >> exported file to the new exported file and checking that they're >> identical). Of course, it might be expected that the tests change. In this >> case, you would want to check the new exported files manually and then save >> the new files as the files to compare to. Does that make sense? It >> shouldn't take much time to implement (although I know that even a little >> time can be hard to find and prioritize). You just run ODT export on a .lyx >> file, say test1.lyx, then save that .odt, test1.save.odt. Then suppose you >> change ODT export. You would have a script that exports test1.lyx to >> test1.odt and then compare test1.odt to test1.save.odt to see if they are >> identical. If they are not identical, then manual inspection would be >> needed to see if the differences are legitimate. If they are, rename >> test1.odt to test1.save.odt (overwriting) and explain the changes in the >> commit message. >> >> Does that make sense? >> > > Thanks, now I understood what you meant. Ya, I guess this should not take > much time to implement. I didn't do this sort of testing in LyX to ODT as I > was not touching any of tex4ht's post-processors. I was only configuring > some new styles and fixing issues with some old ones, so we can say all > were kind of independent changes which don't effect each other(provided > mk4ht doesn't raise any error while running). Whenever I write a wrong XML > syntax, the generated ODT doesn't have a content.xml at all, so I used this > as feedback manytimes. But recently, when I tried converting a real life > lyx doc, then the resultant ODT file turned out to be corrupt. I was not > able to find out why the file was corrupt and I am still wondering on how > to fix these kind of issues. > Hi Prannoy, are you familiar with test-driven development [1]? This is what Scott is referring to (or almost). The basic idea is to write the tests first and then code until your code passes the all the tests (even those you haven't touched in your last iterations). We almost did that in the first phase of the project, but in a very informal manner. I guess Scott is pushing for a more structured and automated testing procedure (which is indeed what test-driven development requires to be effective). I would be very happy to see it happen, at least for the text4ht part. Let me know if you need any help. Cheers, Stefano [1] See http://en.wikipedia.org/wiki/Test-driven_development. Or pick any of the books by Kent Beck for a good introduction. "Test-Driven Development by Example" is a step by step introduction with lots of examples in Python. If you are willing to learn a bit of Smalltalk (strongly recommended), the free book Pharo by Example" (http://pharobyexample.org/) has a short section on unit testing that you may find useful. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: GSOC LyXToWordConversion
Hi Tariq, it is great to hear you are willing to test the work Prannoy did over the summer in the context of Google's summer of code. As Richard pointed out, the code (it's all in .4ht files) is in the gsoc repository, and more precisely in the tests directory. I would just ask you to wait a few more days, as Prannoy is now in the final week of the project and he is moving stuff around and testing a script that allows a the conversion to ODT to be launched directly from the LyX interface, thereby greatly simplifying the testing process. Bug me again in a week or so if you don't hear from me. Cheers, Stefano On Thu, Aug 7, 2014 at 2:00 PM, Richard Heck wrote: > On 08/06/2014 10:52 AM, tesm...@gmail.com wrote: > >> Dear Richard, >> >> Thanks for your reply. >> >> I would like to participate in testing of the GSOC project to >> LyxToWordConversion [http://wiki.lyx.org/GSoC/LyxToWordConversion]. >> >> Would someone please add me to the list and provide the binaries/code for >> testing? >> > > Communication about the project happens on this list. The code is in the > LyX GSOC repository, which you can browse here: > http://git.lyx.org/?p=gsoc.git;a=summary > I'm not sure which branches (listed at the bottom) are part of this > project, but presumably odt2lyx is one of them, as are the lyx2word > branches. > > I'm cc'ing the people mainly involved in this. They can give us more info. > > Richard > > -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Lyx-->Word and Lyx<-->Word: final agreement on projects' goals sought
On Mon, Jul 7, 2014 at 3:47 AM, Wilfried wrote: > stefano franchi wrote: > > > in light of all the recent discussions, my latest report, and the fact > > that GSOC 2014's application window is about to open (March 10), it'd > > be great if we could reach some consensus on the projects' goal and > > approaches. > > > > My current view of the matter is this: > > > > 1. We have two projects: export to Word and round trip conversion to > > be pursued independently > > > > 2. Export to Word requires LaTeX processing and is therefore best > > pursued with tex4ht and by adding/contributing to its own current > > functionalities. > > > > 3. Round trip conversion is best pursued by exporting directing to > > Word XML-based format from within LyX code (i.e. from the C++/Qt > > side) for the LyX-to-Word trip and with either C++/Qt or Python for > > the reverse Word-to-Lyx trip. > > > > N.B. "Word" stands for docx|odt throughout > > Hello, > I already posted this to the lyx-users list (gmane.editors.lyx.general). > I just came across a converter which i wasn't aware of before. > Hi Wilfried, thanks for the pointer. I was unaware of this project, which looks very interesting. I was also quite surprised to see a LaTeX parser written in Prolog---it brought back 30 years old memories Definitely something to keep an eye on. Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: LyX 2.0.8.1 Sources, For Real This Time!
On Mon, Jun 16, 2014 at 2:51 PM, Julien Rioux wrote: > On 16/06/2014 12:52 PM, stefano franchi wrote: > >> On 06/13/2014 06:26 PM, stefano franchi wrote: >>> >>> >>> 2. Configuration fails on the automake version. I have 1.14.1 >>>> installed, and autogen.sh claims LyX only supports versions >>>> up to 1.13. Editing the autogen.sh file to accept 1.14 seems >>>> to fix the problem, though. Unless there are issues with >>>> automake I am unaware of. >>>> >>> Ok. I'll make a one line patch for the Archlinux package then. That >> seems the simplest solution. >> >> >> > Normally you don't need to run autogen.sh from the tarball, you only need > to run it for a git checkout. So no patch should be necessary, unless > something is messed up with the tarball. > You're right of course. It's been so long since I installed from the tarball that I had forgot about autogen being unnecessary. Thanks for reminding me. Cheers, S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: LyX 2.0.8.1 Sources, For Real This Time!
On Mon, Jun 16, 2014 at 11:20 AM, Richard Heck wrote: > On 06/16/2014 12:03 PM, stefano franchi wrote: > > > > > On Sat, Jun 14, 2014 at 4:45 PM, Richard Heck wrote: > >> On 06/13/2014 06:26 PM, stefano franchi wrote: >> >> >>2. Configuration fails on the automake version. I have 1.14.1 >> installed, and autogen.sh claims LyX only supports versions up to 1.13. >> Editing the autogen.sh file to accept 1.14 seems to fix the problem, >> though. Unless there are issues with automake I am unaware of. >> >> >> Probably not, but I don't think that ever got tested with 2.0.x. Is it >> updated in master? >> >> >> > It is. Master supports versions 1.8 to 1.14 > > > OK. Since 2.0.x is now dead, I won't update it there. People who need to > do so can do as you did. > > Ok. I'll make a one line patch for the Archlinux package then. That seems the simplest solution. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: LyX 2.0.8.1 Sources, For Real This Time!
On Sat, Jun 14, 2014 at 4:45 PM, Richard Heck wrote: > On 06/13/2014 06:26 PM, stefano franchi wrote: > > >2. Configuration fails on the automake version. I have 1.14.1 > installed, and autogen.sh claims LyX only supports versions up to 1.13. > Editing the autogen.sh file to accept 1.14 seems to fix the problem, > though. Unless there are issues with automake I am unaware of. > > > Probably not, but I don't think that ever got tested with 2.0.x. Is it > updated in master? > > > It is. Master supports versions 1.8 to 1.14 S. -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: LyX 2.0.8.1 Sources, For Real This Time!
On Fri, Jun 13, 2014 at 5:26 PM, stefano franchi wrote: > > > > On Mon, Jun 2, 2014 at 8:03 AM, Richard Heck wrote: > >> On 06/01/2014 09:36 AM, Stephan Witt wrote: >> >>> Am 30.05.2014 um 17:15 schrieb Richard Heck : >>> >>> The source tarballs for LyX 2.0.8.1 are again at >>>> http://frege.brown.edu/lyx/. Please prepare binaries. I'd like to >>>> release as soon as possible, as 2.0.x users have been asking about 2.0.8 >>>> for a while now. >>>> >>> > > > Richard, > > two issues on 2.0.8.1: > > 1. I had to check out the sources from the git repo, the link you gave > seems to be empty. > My bad, forget about this issue. the sources seem to be on the lyx ftp site already. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: LyX 2.0.8.1 Sources, For Real This Time!
On Mon, Jun 2, 2014 at 8:03 AM, Richard Heck wrote: > On 06/01/2014 09:36 AM, Stephan Witt wrote: > >> Am 30.05.2014 um 17:15 schrieb Richard Heck : >> >> The source tarballs for LyX 2.0.8.1 are again at >>> http://frege.brown.edu/lyx/. Please prepare binaries. I'd like to >>> release as soon as possible, as 2.0.x users have been asking about 2.0.8 >>> for a while now. >>> >> Richard, two issues on 2.0.8.1: 1. I had to check out the sources from the git repo, the link you gave seems to be empty. 2. Configuration fails on the automake version. I have 1.14.1 installed, and autogen.sh claims LyX only supports versions up to 1.13. Editing the autogen.sh file to accept 1.14 seems to fix the problem, though. Unless there are issues with automake I am unaware of. I'd like to prepare a source package for Archlinux for those wishing to stick with the 2.0/.x branch for a while (Arch's LyX support jumped from 2.0.7 directly to 2.1). Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Pdflatex crashes on command line with university pdf logo
On Tue, Jun 10, 2014 at 12:07 PM, Claudius Marpa Heine < claudius.marpa.he...@student.uni-augsburg.de> wrote: > Hi LyX developers, > > I have a bug when I try to use LyX in a command line to create a pdf > using pdflatex, but when I use LyX over the UI it works. > > Here is the command I use: > $ lyx -e pdf2 -f all test.lyx > > Here is the simplest LyX file, where the bug occures: > https://dl.dropboxusercontent.com/u/1512554/lyxbug.7z > > I tried it with LyX 2.1.0 and 2.2.0dev (2014-04-14) > and pdfTeX 3.1415926-2.5-1.40.14 on Archlinux > > On the developer build of LyX the output is: > > Looking for python v2.x ... > Examining /usr/bin/python > Examining /usr/bin/python-config > Examining /usr/bin/python2 > Found Python 2.7.7 > > This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Arch Linux) > restricted \write18 enabled. > entering extended mode > (./test.tex > LaTeX2e <2011/06/27> > Babel <3.9h> and hyphenation patterns for 78 languages loaded. > > Systemcall.cpp (288): Systemcall: 'pdflatex "test.tex"' finished with > exit code 1 > > Have you tried getting rid of the umlaut in the logo's filename (and in the related inset in lyx)? It worked fine here once I did that, with lyx 2.11dev Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Master .bib file
On Tue, Jun 10, 2014 at 11:19 AM, Oliver Sargent wrote: > Hi, > > I am wondering if it is possible to have some kind of Master .bib file > which would (for instance) include all bibtex entries from mathscinet, the > file could be hosted remotely and updated periodically and everyone could > download his or her own copy. > > In my opinion this would be a nice feature, I guess for latex in general, > but the advantage of doing it from within Lyx, is that you do not need to > remember the labels of citation since the search function in the cite > dialoge box is very nice (seems roughly equivalent to a search on > mathscinet). > > This sounds more like a job for a bibtex reference manager. Many such managers (e.g. jabref, bibdesk) allows querying of remote databases and importing bibtex-format references. The ref(s) can then be pushed to LyX through the pipe (LyX server) system. BTW, MathSciNet is not a free service (although it appears as such to most academic users, since the university picks up the tab). I sincerely doubt they would allow anyone to download their database (or to upload it to the cloud). But even if they did, who would then take care of maintaining such a copy? Cheers, Stefano > Best wishes > > Oli > -- ______ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
[GSOC/LyX<-->Word]: Math export to ODT issues
Dear all, I would love to get some feedback on the issue of Math export to OpenOffice's ODT, which Prannoy is currently working on. We have a fairly comprehensive test document (lifted from the latex2rtf project) with many different kinds of math expressions. In total, there are 73 math constructs (both inline and display). Tex4ht converts these expressions to self-standing MathML files (later embedded in the ODT file) and inserts the correct references in the main document. Unfortunately, the final converted file has many errors. To be precise 14 out of the 72 expressions are not correctly visualized. However, a careful review of the code produced by tex4ht reveals that the MathML expressions it produces are indeed correct in all cases but one. It is OpenOffice that fails to properly render the MathML code. Put it otherwise: of the 14 rendering errors, 13 turn out to be OpenOffice bugs, and 1 a tex4ht bug. I don't think there is much we can do about the the OpenOffice bugs, beside filing reports. Besides, a quick survey of the Libre|OpenOffice forums shows that indeed MathML's support is far from satisfactory, but no one, as far as I can tell, is apparently working on it. It is very low priority. So here is the question: how do we proceed on the math conversion front? 1. Should we concentrate on creating a system to export the original LaTeX expressions as annotation fields in the ODT file for the roundtrip conversion? 2. Or should we perhaps explore ways to get around the existing problems, such as, for example, converting the troublesome expressions to images instead of MathML? I guess the answer depends on the user scenarios. If cooperation for final production of pdf from LyX is primary, we should go for (1). If a final export to ODT aimed to either publishers or public at large is the goal, perhaps we should investigate (2). I am not a heavy math user by any means, so my imagination is kind of lacking on this front. Cheers, Stefano -- ______ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Lyx<-->Word conversion and images: suggestions sought
On Tue, Jun 3, 2014 at 2:57 PM, Georg Baum wrote: > stefano franchi wrote: > > > Prannoy has worked out how to instruct tex4ht to use "convert" and > > produce png from pdf. I guess he could substitute a conversion to EPS > > instead (with pdftops -eps), but I am not sure if there is any real > > benefit. I am really having troubles imagining a scenario in which a > > self-contained, converted ODT file would be used to produce high-quality > > printed output. But I may be lacking imagination. > > I have no idea whether that scenario is used. However, it is not important > right now IMHO: If tex4ht can be made to call convert, then it could use > any > converter later if needed (in theory). > > That (calling convert) was achieved in the last few days. It is even capable of passing the \includegraphics scaling parameter to it, so that both pdf's (once converted to png) and png's are converted and scaled appropriately. To simplify tex4ht's level support for conversion (which is not pretty, let alone readable) I think we could limit it to support the graphics format pdflatex itself (and its followers such as XeTeX and LuaTeX) supports: pdf, jpeg, png. If the user inserts images in some other format (since LyX supports more) the conversions to these three formats can be done by LyX itself on export to ODT, as it does now on export to pdflatex. At any rate, Prannoy is now moving to tex4ht's math support, where I expect thornier issues will come up soon. Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Lyx<-->Word conversion and images: suggestions sought
On Mon, Jun 2, 2014 at 2:02 PM, Georg Baum wrote: > stefano franchi wrote: > > > On Fri, May 30, 2014 at 3:42 PM, Georg Baum > > wrote: > > > Under this assumption, we are free to delegate both image conversion and > > directory flattening to LyX and we only need to make sure the ODT file > has > > the correct metadata to recreate the image reference as originally stored > > in the LyX file. > > And we can avoid storing the original image *in* the ODT file (if that's > > possible, I don't know). > > Sounds sensible. However, it is hard to believe that the odt format does > not > support at least one vector graphics and one bitmap graphics format. I > would > guess that it is possible (with some effort) to store good quality images > inside the .odt (but this is rather a long term thought, nothing for now). > > You're right, I didn't make myself clear again. LIbreoffice supports a number of graphic formats. Not pdf though. It does support EPS and SVG, plus a number of common bitmap formats such as png, gif, jpeg, etcetera. (SVG does not seem to work well, thougg, at least not with my inkscape-generated SVG files). Prannoy has worked out how to instruct tex4ht to use "convert" and produce png from pdf. I guess he could substitute a conversion to EPS instead (with pdftops -eps), but I am not sure if there is any real benefit. I am really having troubles imagining a scenario in which a self-contained, converted ODT file would be used to produce high-quality printed output. But I may be lacking imagination. Cheers, S. > Georg > > > -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: The Mystery Crash Is NOT Triggered By Auto-Save
On Mon, Jun 2, 2014 at 6:17 PM, Cyrille Artho wrote: > > > stefano franchi wrote: > >> >> >> >> On Mon, Jun 2, 2014 at 6:08 PM, Cyrille Artho > <mailto:c.ar...@aist.go.jp>> wrote: >> >> >> stefano franchi wrote: >> >> >> >> >> On Mon, Jun 2, 2014 at 5:54 PM, Cyrille Artho > <mailto:c.ar...@aist.go.jp> >> <mailto:c.ar...@aist.go.jp <mailto:c.ar...@aist.go.jp>>> wrote: >> >> Dear all, >> It looks like in the long term, a grammar-based random >> document >> generator for LyX would be very useful for testing. The >> "grammar" would >> contain rules about how a document looks like: Title, >> authors, >> abstract, sections with subsections and >> text/tables/figures/equations. >> Tables/figures/equations would again be generated by other >> rules. >> >> Of course content does not matter, as long as the result is a >> valid >> .lyx file. For testing, the result would be loaded by lyx and >> saved >> again. This would ensure a document does not get corrupted by >> saving, >> no matter how strange it is. >> >> However, it is a significant effort to build a decent >> document >> generator that is useful for such testing... something that >> may fit for >> GSoC, though. I'll keep this in mind for 2015. >> >> >> Excellent idea, although the sheer variety of things to test >> makes the >> problem hard. Perhaps this would be a good starting point: >> >> http://pdos.csail.mit.edu/__scigen/ <http://pdos.csail.mit.edu/ >> scigen/> >> >> >> S. >> >> Yes, that could be a starting point, although the code may not be easy >> to edit. In any case, we'd need LyX files, and also tables (perhaps >> even equations) that are non-trivial but still syntactically correct. >> >> >> >> >> >> There are a number of automatic paper generators out there, for different >> disciplines (LitCrit, of course, then math, CS, etc). They tend to be >> Perl-based (unsurprisingly) and LaTeX-oriented. It seems doable to >> repurpose and/or integrate some of them toward LyX. Not sure it's a >> GSOC-level project though. >> >> S. >> >> The size of the project depends a bit on the scope (especially on how > complex the documents/tables should be). We shouldn't forget that the > project needs a good test driver, too, which requires generating the right > LyX user actions to save a previously loaded document, and compares the > outputs. (Maybe it is even possible that the first LyX save has to be > loaded and saved again for the output to be "stable", as a document > generator may produce slightly different files than LyX itself.) > > The test driver has to do this many times while catching crashes/timeouts > reliably. So this also takes a few weeks to automate. Add the document > generation itself, and consider everything is done by someone new to the > problem, and it's easy to stretch this to three months, I think. > > Oh, you misunderstood me. My guess was it *can't* be done in three months. Not by an undergraduate-level student, that is. At any rate, I do agree that it is an idea we should keep present for next year's GSOC. Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: The Mystery Crash Is NOT Triggered By Auto-Save
On Mon, Jun 2, 2014 at 6:08 PM, Cyrille Artho wrote: > > stefano franchi wrote: > >> >> >> >> On Mon, Jun 2, 2014 at 5:54 PM, Cyrille Artho > <mailto:c.ar...@aist.go.jp>> wrote: >> >> Dear all, >> It looks like in the long term, a grammar-based random document >> generator for LyX would be very useful for testing. The "grammar" >> would >> contain rules about how a document looks like: Title, authors, >> abstract, sections with subsections and text/tables/figures/equations. >> Tables/figures/equations would again be generated by other rules. >> >> Of course content does not matter, as long as the result is a valid >> .lyx file. For testing, the result would be loaded by lyx and saved >> again. This would ensure a document does not get corrupted by saving, >> no matter how strange it is. >> >> However, it is a significant effort to build a decent document >> generator that is useful for such testing... something that may fit >> for >> GSoC, though. I'll keep this in mind for 2015. >> >> >> Excellent idea, although the sheer variety of things to test makes the >> problem hard. Perhaps this would be a good starting point: >> >> http://pdos.csail.mit.edu/scigen/ >> >> S. >> >> Yes, that could be a starting point, although the code may not be easy > to edit. In any case, we'd need LyX files, and also tables (perhaps even > equations) that are non-trivial but still syntactically correct. > > > There are a number of automatic paper generators out there, for different disciplines (LitCrit, of course, then math, CS, etc). They tend to be Perl-based (unsurprisingly) and LaTeX-oriented. It seems doable to repurpose and/or integrate some of them toward LyX. Not sure it's a GSOC-level project though. S. __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: The Mystery Crash Is NOT Triggered By Auto-Save
On Mon, Jun 2, 2014 at 5:54 PM, Cyrille Artho wrote: > Dear all, > It looks like in the long term, a grammar-based random document generator > for LyX would be very useful for testing. The "grammar" would contain rules > about how a document looks like: Title, authors, abstract, sections with > subsections and text/tables/figures/equations. Tables/figures/equations > would again be generated by other rules. > > Of course content does not matter, as long as the result is a valid .lyx > file. For testing, the result would be loaded by lyx and saved again. This > would ensure a document does not get corrupted by saving, no matter how > strange it is. > > However, it is a significant effort to build a decent document generator > that is useful for such testing... something that may fit for GSoC, though. > I'll keep this in mind for 2015. > Excellent idea, although the sheer variety of things to test makes the problem hard. Perhaps this would be a good starting point: http://pdos.csail.mit.edu/scigen/ S. -- ______ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: The Mystery Crash Is NOT Triggered By Auto-Save
On Mon, Jun 2, 2014 at 11:11 AM, Jürgen Spitzmüller wrote: > 2014-06-02 17:43 GMT+02:00 stefano franchi: > > Lastly, crashes are not system-generated, they always occur immediately >> after some action (opening a menu, switching tabs, etc.). >> > > This sounds like bugs that have been resolved for 2.1.1 (especially the > menu-related crashes). > > But to be sure, we'd need backtraces. > > Good point. Rebuilding with latest version right now. Cheers, S. -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Fwd: The Mystery Crash Is NOT Triggered By Auto-Save
On Sat, May 31, 2014 at 5:02 PM, Richard Heck wrote: > On 05/31/2014 07:19 AM, Jean-Marc Lasgouttes wrote: > >> Le 31/05/2014 10:43, Jürgen Spitzmüller a écrit : >> >>> Am Freitag 30 Mai 2014, 15:06:36 schrieb Richard Heck: >>> >>>> The fact that everything always ends with \begin_inset Tabular confuses >>>> me. As soon as we write that, we go into Tabular::write(). And, assuming >>>> we actually make it there, the next thing we do is output ">>> and a bunch of similar info. Why doesn't any of that show up in the >>>> output file? Is there some kind of buffering going on? If so, would it >>>> be worth disabling that, so the corrupted files would give us more >>>> information about exactly where we are crashing? It's hard to see that >>>> there is anything in Tabular::write() itself that could cause a crash, >>>> except bad vector access, and it's hard to see why that would happen so >>>> intermittently. My guess is that the crash comes when writing some >>>> particular cell, but who knows? >>>> >>> >> Note that InsetTabular::write flushes the stream with a endl, and that >> Tabular::write does not use endl at all. Actually, I m not sure that there >> are many places where endl is used as in this case. And if >> InsetTabular::write is the only one to use endl, then it may not be a >> surprise that the truncated files stop there. >> >> IOW, it may be that the bug is not really related to tabular inset. >> > > Yes, that's true. Though, in most of the reports I have seen of this > crash, the user was doing something with a table when the crash occurred. > It's a wild guess, but I'm wondering if putting the cursor into a certain > cell (multirow, multicolumn?) and doing something there could leave the > table in an inconsistent state, and the attempt to write it then crashes. > > I am getting a lot of crashes with 2.1, and they are completely unrelated to tables. I only use 2.1 for the LyX/Word GSOC project, and I have it always open with the project's test files open. No tables. I may do some work on the files once a day, so it's not heavily used. LyX crashes at least once a day, often more than once. The crash message is the usual, uninformative "SIGSEV signal caught...". I have not experienced any data loss, but then again, I would not expect any, as my edits to the open files are minimal and I save immediately. I do have auto-save on at the default 5 minutes. Lastly, crashes are not system-generated, they always occur immediately after some action (opening a menu, switching tabs, etc.). This behavior may be totally unrelated to the problem under discussion, but I thought I would add another data point. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: lyxpak not working
On Sun, Jun 1, 2014 at 1:51 PM, Kornel Benko wrote: > Am Sonntag, 1. Juni 2014 um 20:48:03, schrieb Kornel Benko > > > > > You could try to trace it, like this on linux: > > > > # strace -f -o xx /usr/bin/python2 -tt > "/usr/local/share/lyx-2.1/scripts/lyxpak.py" > > > > > S. > > > Thanks Kornel. strace worked and found the root of the problem It is definitely an installation problem: the python module collections.py try to load an internal C module called _collections and fails to find it. The module is actually present on my system at /usr/lib/python2.7/lib-dynload/_collections.so but somehow python2 cannot find it. Still trying to find a solution. Cheers, S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: lyxpak not working
On Sun, Jun 1, 2014 at 1:24 PM, stefano franchi
wrote:
> Dear All:
>
> I am trying to use lyxpak and it fails due to python-related issues. This
> happens both in lyx2.1 and 2.0. I think it maybe a platform-specific issue
> (Arch) due to some environmental variables not set by default, or to some
> python2/python3 conflict. At any rate, I can't figure out how to fix it.
> Here is the error message:
>
> 12:56:57.302: Fatal Python error: Py_Initialize: Unable to get the locale
> encoding
>
> 12:56:57.303: File "/usr/lib/python2.7/encodings/__init__.py", line 123
>
> 12:56:57.304: raise CodecRegistryError,\
>
> 12:56:57.305: ^
>
> 12:56:57.306: SyntaxError: invalid syntax
>
>
>
> which is puzzling, since it seems to say that there is a problem with the
> syntax of the raise statement. Source code of the encodings file:
>
>
> if not isinstance(entry, codecs.CodecInfo):
> if not 4 <= len(entry) <= 7:
> raise CodecRegistryError,\
> 'module "%s" (%s) failed to register' % \
> (mod.__name__, mod.__file__)
>
>
> As far as I can tell, the syntax of raise used here is indeed wrong if
> used in python 3 (where raise Exception("excp") should be used). But why is
> python 3 called at all, when lyxpak is correctly called as
>
> /usr/bin/python2 -tt "/usr/local/share/lyx-2.1/scripts/lyxpak.py" ?
>
>
> Secondly, the fact that the encodings module tries to raise an exception
> means it has failed to find the correct module, I think.
>
>
> So the two problems are most likely just one problem, due to some
> interaction between python2 and python 3 on my system.
>
>
> Any suggestion?
>
>
>
>
Further info:
- "python" defaults to python3 on my system
- my python3 installation is broken, and indeed launching "python" from
the command line gives me exactly the same error as lyxpak.py
So the issue seems to be that lyxpak indirectly calls "python" at some
points, this calls ends up calling python3, which fails.
I still do not understand where this misguided call to python3 comes into
the picture, though.
S.
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
lyxpak not working
Dear All:
I am trying to use lyxpak and it fails due to python-related issues. This
happens both in lyx2.1 and 2.0. I think it maybe a platform-specific issue
(Arch) due to some environmental variables not set by default, or to some
python2/python3 conflict. At any rate, I can't figure out how to fix it.
Here is the error message:
12:56:57.302: Fatal Python error: Py_Initialize: Unable to get the locale
encoding
12:56:57.303: File "/usr/lib/python2.7/encodings/__init__.py", line 123
12:56:57.304: raise CodecRegistryError,\
12:56:57.305: ^
12:56:57.306: SyntaxError: invalid syntax
which is puzzling, since it seems to say that there is a problem with the
syntax of the raise statement. Source code of the encodings file:
if not isinstance(entry, codecs.CodecInfo):
if not 4 <= len(entry) <= 7:
raise CodecRegistryError,\
'module "%s" (%s) failed to register' % \
(mod.__name__, mod.__file__)
As far as I can tell, the syntax of raise used here is indeed wrong if used
in python 3 (where raise Exception("excp") should be used). But why is
python 3 called at all, when lyxpak is correctly called as
/usr/bin/python2 -tt "/usr/local/share/lyx-2.1/scripts/lyxpak.py" ?
Secondly, the fact that the encodings module tries to raise an exception
means it has failed to find the correct module, I think.
So the two problems are most likely just one problem, due to some
interaction between python2 and python 3 on my system.
Any suggestion?
Cheers,
Stefano
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: Lyx<-->Word conversion and images: suggestions sought
On Fri, May 30, 2014 at 3:42 PM, Georg Baum wrote: > stefano franchi wrote: > > > Dear all: > > > > Prannoy just hit upon a problem in text4ht conversion of images to odt > > format. > > This is what text4ht should do: > > > > 1. Read the correct reference from the tex file > > 2. If necessary, covert the image to a suitable (bitmap) format for > > inclusion in the odt file > > The image conversion could also be delegated to LyX: If LyX would know that > a LaTeX export is in reality for odt production, it could use its own > converter machinery and provide both the file needed for tex4ht and for > inclusion in odt. The advantage would be that the conversion would always > start from the original image, which can result in higher quality or no > conversion at all (e.g. if the original image is suitable for odt but not > tex). > > Excellent point. I hadn't thought of this. So let's say LyX's existing converters take care of the conversions. > > 3. copy the converted image to a proper subfolder in the odt file (which > > really is a zipped archive, as you know). > > > > The system works fine if the images are in the same directory/folder as > > the .tex source file, but tex4ht gets its references screwed up > otherwise. > > It copies the images to the right "internal" folder (inside the odt > file), > > but the xml code is incorrect and libreoffice cannot find the images when > > you open the file. > > Why is it important to have the same directory structure inside the .odt as > the user uses for LyX outside? This structure is internal, the user never > sees it. Therefore I'd simply use a flat structure internally, and no > tex4ht > changes are required. > Sorry, I didn't explain the problem correctly. Of course, the internal structure of the ODT file should not matter. But tex4ht, instead, tries (and fails) to recreate the folder structure *inside* the odt zipped archive. That's the (known) bug. Example: Say I have a tex file test.tex in folder "Folder" which contains a png image picture.png in the same folder. tex4ht will create ODT file containing a subfolder called "Pictures" and put image.png in it, then insert the correct reference in the content.xml file, and everything works fine. But now say the image is in Folder/Figures/picture.png. Tex4ht will create a folder called Pictures/Figures inside the ODT archive, and will screw up the reference to it in the content.xml file. What it should do is to act similarly to the previous case: copy the image to the Pictures folder an *not* try to recreate the folder structure. > Rather than messing up with with tex4ht code, it seems to me the easier > workaround is to copy all the images and the tex source file to a > temporary folder and do the conversion there. This is a similar approach > to what LyX itself does before compiling LaTeX, in fact, and it is also > what the native HTML converter does, I believe. If you execute the converter as part of the standard conversion chain in > LyX, then LyX will automatically flatten the directory structure, and all > included files are in the same directory as the .tex file itself. > > Good point. > > Issues on which feedback is welcome: > > > > 0. General thoughts about the approach (copying images vs. fixing tex4ht > > processing) > > > > 1. My thinking is that it may be relatively easy to do the copying by > > operating on the LyX source code, i.e. via a python script scanning the > > Graphics inset. That would tie the tool to the file format, though. > > I would avoid that if possible, since this introduces ambiguity: Suddenly > you read contents both from .tex and .lyx files. How do you ensure that > these two files are consistent?. If it is really too difficult to fix > tex4ht, then I'd rather scan the .tex file (similar to > lib/scripts/tex_copy.py) instead. > > I'll take a look at tex_copy.py. Seems like the best way to go, at least in the interim. > > 2. For the roundtrip conversion, we also need to keep the original > > filename references and store them somewhere in the odt file (in an > > annotation field). Are there any platform-related issues on filenames we > > should be aware of (encoding, folder delimiters, etc)? > > There are several (http://wiki.lyx.org/LaTeX/FilesWithSpecialChars might > help). What would you do with absolute paths? It may be impossible to > restore them. Folder delimiters are easy, you can use forward slashes for > internal storage, just as in LyX. The encoding is always the one which is > active in the .tex file at the place where the filename occurs. Also keep > in > mind that for master/
Re: Lyx<-->Word conversion and images: suggestions sought
On Thu, May 29, 2014 at 6:41 PM, Cyrille Artho wrote:
> Dear all,
> My thoughts:
>
> I think it is not too uncommon to have two images with the same name in
> different directories, such as pics/old/arch.fig and pics/new/arch.fig.
>
> Obviously in such cases the renaming scheme needs to take this into
> account, by converting path separators ("/") to another character. However,
> that in turn means that that "other character" should not appear in the
> file name, so a means of "escaping" it would be needed as well.
>
> For example: Path separators get converted to "_-"; "_" get converted to
> "__". In that case, a reverse substitution is always possible.
>
> In short, the solution is workable but has its drawbacks.
>
> If it's possible to fix tex4ht instead, that would be better as tex4ht
> users would also benefit. I agree that the code is not so easy to
> read/maintain, but this may be a good starting point.
>
> A full "flattening" of path separators has the advantage that we don't
> have to worry about the platform the resulting document is used on. In
> other words, if we export a nested path name, then the target computer has
> to understand the path delimiter in the same way as the source computer. I
> guess nowadays any computer understands "/" so maybe this is not an issue
> with .odt. If "/" can indeed by used for .odt path names even on Windows,
> then keeping the original path names may be the more elegant solution, even
> if fixing tex4ht may be a bit difficult.
>
>
Good points Cyrille, thanks for the feedback.
Prannoy is now working on related issues in image conversion and set aside
this particular problem for the moment. I guess a more thorough
investigation of why tex4ht gets the references wrong would be warranted,
and it is not an easy task.
Cheers,
Stefano
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: [Feature Request] quality ePub export: Was [Feature Request] python binding
Hi Steve, I am bringing this back to the lyx-devel list, where it belongs (I responded privately by mistake) On Thu, May 29, 2014 at 9:14 PM, Steve Litt wrote: > On Thu, 29 May 2014 14:55:02 -0500 > stefano franchi wrote: > > > On Thu, May 29, 2014 at 2:35 PM, Steve Litt > > wrote: > > > > > On Thu, 29 May 2014 14:36:29 -0500 > > > "Alex Vergara Gil" wrote: > > > > > > > Hello Lyxers > > > > > > > > I wonder why LyX is not available to process little pieces of > > > > python code within its own framework, like ipython notebook for > > > > instance?? This feature allows us to have beautiful graphics such > > > > the one produced by matplotlib package. I know there already > > > > exists a similar binding for R through knitr module, so why not a > > > > binding for python too?? > > > > > > > > Is there a way, like modules or whatever, to achieve the same > > > > functionality or at least some basic functionality of ipython > > > > notebook within LyX?? > > > > > > Oh, if we're going consider requests for difficult additions to > > > handle a small subset of needs like beautiful graphics, how about > > > filling the GAPING HOLE that there's no practical way to export to > > > ePub, without massive human intervention and end-user programming? > > > None of LyX's HTML and xHtml exports are remotely suitable for > > > flowing-text eBook production, especially because different people > > > have different ideas of how eBooks should be built. > > > > > > Personally, I think the easiest way forward on this is to take the > > > current half XML half something else native format, and make it well > > > formed XML. No doing favors of renaming graphics files with > > > arbitrary numbers, no doing favors of making obvious hierarchy into > > > , just make the native format XML and let anyone with Python > > > and lxml.etree have his way with the native LyX file. > > > > > > I know that two years ago I railed against XML native format, but > > > parsers have gotten better, and right now we have the human > > > unreadability of XML, combined with the unparsability of a more TeX > > > like language. Well formed XML can only be an improvement. > > > > > > If well formed XML native format is not practical in the near > > > future, perhaps somebody could make a program that exports the > > > current native format into well-formed XML, once again without > > > renumbering, throwing away structure, etc. Basically, just pass the > > > environments through: No need to map Part to , once it's XML, > > > we can trivially do that ourselves, the way we want to. Given that > > > most eBooks don't do a lot of bibliography stuff, you could even > > > have an initial version that has hooks for the bibliography stuff > > > but doesn't actually do it. Put in the bibliographies next time. If > > > it's not perfect with math, that's fine: I can't think of anything > > > more frustrating than trying to read a math book on a small device. > > > > > > Because of LyX's inability to author flowing text eBooks in any > > > reasonable way, I haven't used LyX in 9 months: I'm authoring with > > > Bluefish now. Slow, difficult, crashy, but at least my source > > > document can produce both print, PDF and ePub. > > > > > > Maybe it's just me, but if there's one feature LyX should really > > > have in 2014, I think that one feature is a reasonable export > > > mechanism to something that can be turned into ePub, without > > > undoing all the BS the current LyX (x)Html converters throw into > > > the export. > > > > > > Mark my words: Within two years, beautiful graphics won't matter one > > > bit if the document can't be read on a small device. > > > > > > > > > > Steve, > > > > would the ODT converter that is the topic of one of our GSOC projects > > work for the task you are pushing for? > > After all, ODT *is* XML (for some reading of XML). I know too little > > about the XML and e-pub formats to answer that question, but perhaps > > you could take a look at the project description on the wiki [1] and > > let us know what you think? > > The project currently targets a subset of LyX's full functionalities > > (only one class, only a subset of graphic formats, etc
Lyx<-->Word conversion and images: suggestions sought
Dear all: Prannoy just hit upon a problem in text4ht conversion of images to odt format. This is what text4ht should do: 1. Read the correct reference from the tex file 2. If necessary, covert the image to a suitable (bitmap) format for inclusion in the odt file 3. copy the converted image to a proper subfolder in the odt file (which really is a zipped archive, as you know). The system works fine if the images are in the same directory/folder as the .tex source file, but tex4ht gets its references screwed up otherwise. It copies the images to the right "internal" folder (inside the odt file), but the xml code is incorrect and libreoffice cannot find the images when you open the file. Rather than messing up with with tex4ht code, it seems to me the easier workaround is to copy all the images and the tex source file to a temporary folder and do the conversion there. This is a similar approach to what LyX itself does before compiling LaTeX, in fact, and it is also what the native HTML converter does, I believe. Issues on which feedback is welcome: 0. General thoughts about the approach (copying images vs. fixing tex4ht processing) 1. My thinking is that it may be relatively easy to do the copying by operating on the LyX source code, i.e. via a python script scanning the Graphics inset. That would tie the tool to the file format, though. 2. For the roundtrip conversion, we also need to keep the original filename references and store them somewhere in the odt file (in an annotation field). Are there any platform-related issues on filenames we should be aware of (encoding, folder delimiters, etc)? Cheers, Stefano -- ______ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSOC/Lyx<-->Word]
On Wed, May 21, 2014 at 4:59 AM, aparsloe wrote:
>
> On 21/05/2014 10:14 a.m., stefano franchi wrote:
>
>> Dear all,
>>
>> Prannoy is delving into tex4ht to tweak it to our purposes (quite
>> successfully so far). In the process, he is also trying to understand
>> better tex4ht's rather complex LaTeX code and grasp the logic of the XML
>> constructions it carries out.
>> The problem is that several Latex macros used are quite obscure (and
>> undocumented, as far as I can tell). I append a code fragment below as an
>> example.
>>
>> The general question I'd like to ask is the following though:
>>
>> * How would you go about finding the definition of a (La)TeX command
>> (length, etc.) when you don't know where it may come from?
>>
>> For instance, for "\BegEnd:D" in the code fragment below, I tried
>> grepping the whole tree (which includes tex4ht sources), looking in
>> existing documentation, and compulsing the usual references (TeX book,
>> LTC, etc). To no avail.
>>
>> Do any of the LaTeX gurus around have any suggestions? Am I missing
>> something obvious?
>>
>>
>> Cheers,
>>
>> Stefano
>>
>> --Code fragment from tex4ht's definition of a list (first
>> part only)
>>
>> \ConfigureList{description}%
>>{\EndP
>> \bgroup
>> \HCode{> text:style-name="description\if@rl-rtl\fi"
>> text:name="description"\Hnewline>}%
>> \PushMacro\end:itm
>> \global\let\end:itm=\empty
>> \HTML:PAR{dd|}{dd|}%
>> \gHAdvance\BegEnd:D by 1
>>}
>>
>> --
>> __
>> Stefano Franchi
>>
> This is almost certainly wrong, judging by the code around it that you
> provide above, but the ":D" notation occurs in the expl3 language of LaTeX3
> (as do a host of other "argument specifiers" like ":N", ":n" etc.). See the
> document "interface3.pdf", p.1 of the text, that is available after
> installing the l3kernel bundle.
>
>
Hi Andrew,
thank you for the pointer to the expl3 language.Things are starting to get
clearer! I had assumed that that the use of ":D" were similar to the
ubiquitous "@" for LaTeX's internal commands. I now see I was completely
off.
Thanks,
S.
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: [GSOC/Lyx<-->Word]
On Tue, May 20, 2014 at 5:48 PM, Cyrille Artho wrote: > Dear Stefano, > Could it be that this defines nesting through custom macros? Then you can > maybe find "BegEnd" in the sources elsewhere, but not "\BegEnd:D" (assuming > the code to parse the backslash may also be shared among macros). > > Hi Cyrille, that's exactly what I tried actually: grep -rn BegEnd /usr/local/texlive/ I get many hits, all from the same file (which happens to be the tex4ht file from which I lifted the snippet enclosed in my message). But no definition.Very puzzling. S. -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
[GSOC/Lyx<-->Word]
Dear all,
Prannoy is delving into tex4ht to tweak it to our purposes (quite
successfully so far). In the process, he is also trying to understand
better tex4ht's rather complex LaTeX code and grasp the logic of the XML
constructions it carries out.
The problem is that several Latex macros used are quite obscure (and
undocumented, as far as I can tell). I append a code fragment below as an
example.
The general question I'd like to ask is the following though:
* How would you go about finding the definition of a (La)TeX command
(length, etc.) when you don't know where it may come from?
For instance, for "\BegEnd:D" in the code fragment below, I tried grepping
the whole tree (which includes tex4ht sources), looking in existing
documentation, and compulsing the usual references (TeX book, LTC, etc).
To no avail.
Do any of the LaTeX gurus around have any suggestions? Am I missing
something obvious?
Cheers,
Stefano
--Code fragment from tex4ht's definition of a list (first part
only)
\ConfigureList{description}%
{\EndP
\bgroup
\HCode{}%
\PushMacro\end:itm
\global\let\end:itm=\empty
\HTML:PAR{dd|}{dd|}%
\gHAdvance\BegEnd:D by 1
}
--
__________
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: Segfault in comparing documents
On Fri, May 16, 2014 at 8:40 AM, Jean-Marc Lasgouttes wrote: > 16/05/2014 15:33, stefano franchi: > > [repost as I sent it to the wrong lyx list by mistake] >> >> I never use the "compare documents" feature and while trying it out >> today I got a segfault. I enclosed what I got in the terminal below. >> The culprit seems to be the lack of a "Title*" environment in one of the >> two layouts. The two papers I compared used two different Springer >> classes/layout (LNCS and svn-mono), and only one of them has indeed >> Title*. >> Changing the environment to a regular Title allowed LyX to fix the issue. >> >> I did not find any related bug on the tracker, btw, but I may have >> missed it. >> >> Any more info I should add to the bug report? >> > > This looks like a new bug indeed. Please add two simple example files to > the bug report. I am surprised actually that it is possible to compare two > files with different textclesses. > > Done: http://www.lyx.org/trac/attachment/ticket/9125/ S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Segfault in comparing documents
[repost as I sent it to the wrong lyx list by mistake] I never use the "compare documents" feature and while trying it out today I got a segfault. I enclosed what I got in the terminal below. The culprit seems to be the lack of a "Title*" environment in one of the two layouts. The two papers I compared used two different Springer classes/layout (LNCS and svn-mono), and only one of them has indeed Title*. Changing the environment to a regular Title allowed LyX to fix the issue. I did not find any related bug on the tracker, btw, but I may have missed it. Any more info I should add to the bug report? Cheers, Stefano terminal output: lyx: SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help->Introduction' and send us a bug report, if necessary. Thanks! Bye. Error: LyX crashed! -- -- SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help->Introduction' and send us a bug report, if necessary. Thanks! Bye. We failed to find the layout 'Title*' in the layout list. You MUST investigate! Plain Layout Standard Section Subsection Subsubsection Paragraph Subparagraph Chapter* Section* Subsection* Subsubsection* Paragraph* Subparagraph* Quotation Quote Verse --Separator-- Labeling Itemize Enumerate Description List Title Subtitle Running LaTeX Title TOC Title Author Author Running TOC Author Institute Email Abstract Bibliography Case Claim Conjecture Corollary Definition Example Exercise Lemma Note Problem Proof Property Proposition Question Remark Solution Theorem lassert.cpp (35): ASSERTION false VIOLATED IN TextClass.cpp:1131 Segmentation fault (core dumped) -- ______ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Feature request
On Tue, Apr 29, 2014 at 11:20 AM, Richard Heck wrote:
> On 04/28/2014 06:10 PM, stefano franchi wrote:
>
>
>
>
> On Mon, Apr 28, 2014 at 4:14 PM, Tommaso Cucinotta wrote:
>
>> On 28/04/14 19:37, Patrick O'Keeffe wrote:
>>
>> I don't personally see any advantage to composing emails in Lyx. OP
>> suggested it because of the beautiful formatting provided by LaTeX but HTML
>> isn't capable of such beauty. If you need the aesthetics, you're stuck
>> emailing it as an attachment anyway.
>>
>>
>> Forget about beauty, this is about functionality and convenience:
>> copying from LyX (trunk), I can send you this (I hope you can display it
>> correctly, at least it shows up OK while I'm composing it):
>>
>> - For each hosts pair ( j 1 , j 2 ) ∈ H × H , a set P j 1 , j 2 of
>>interconnection paths may be available and usable, where each path p ∈ P j
>>1 , j 2 is associated with the sequence P j 1 , j 2 ,p of its L j 1 , j 2
>>,p links P j 1 , j 2 ,p ={ ( a j 1 , j 2 ,p,1 , b j 1 , j 2 ,p,1 ), … ,( a
>>j 1 , j 2 ,p, L j 1 , j 2 ,p , b j 1 , j 2 ,p, L j 1 , j 2 ,p ) } ⊂ L .
>>
>>
>> Leaving the meaning aside, my question is: how can I write this in
>> Thunderbird? The only way is to attach the .lyx document, or an export of
>> it, and it takes just more time to do that, rather than copy/paste.
>>
>>
> Tommaso,
>
> I don't know what you see in Thunderbird, but I can assure you that in
> gmail your formula is barely legible. Wouldn't it be easier to "typeset" it
> in ascii?
>
>
> FWIW, it is perfect here in Thunderbird.
>
Too bad for gmail then. I wonder if other webmail clients behave as
horribly.
S.
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: Procedure for porting patch to latest trunk
On Tue, Apr 29, 2014 at 2:07 AM, Sushant Raikar wrote: > > Can i create local branches for my convenience for example > gsoc/interactive/patchupdate? > > Hi Sushant, I would suggest you create your personal branch within gsoc/interactive (call it 'sushant') and use that branch as your personal playground: create test branches, etc. Cheers, Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Feature request
On Mon, Apr 28, 2014 at 4:14 PM, Tommaso Cucinotta wrote:
> On 28/04/14 19:37, Patrick O'Keeffe wrote:
>
> I don't personally see any advantage to composing emails in Lyx. OP
> suggested it because of the beautiful formatting provided by LaTeX but HTML
> isn't capable of such beauty. If you need the aesthetics, you're stuck
> emailing it as an attachment anyway.
>
>
> Forget about beauty, this is about functionality and convenience: copying
> from LyX (trunk), I can send you this (I hope you can display it correctly,
> at least it shows up OK while I'm composing it):
>
> - For each hosts pair ( j 1 , j 2 ) ∈ H × H , a set
>P j 1 , j 2 of interconnection paths may be available
>and usable, where each path p ∈P j 1 , j 2is
>associated with the sequence P j 1 , j 2 ,p of its
>L j 1 , j 2 ,p links P j 1 , j 2 ,p ={ (
>a j 1 , j 2 ,p,1 , b j 1 , j 2 ,p,1), … ,( a
>j 1 , j 2 ,p, L j 1 , j 2 ,p , b j 1 , j 2
>,p, L j 1 , j 2 ,p ) } ⊂ L .
>
>
> Leaving the meaning aside, my question is: how can I write this in
> Thunderbird? The only way is to attach the .lyx document, or an export of
> it, and it takes just more time to do that, rather than copy/paste.
>
>
Tommaso,
I don't know what you see in Thunderbird, but I can assure you that in
gmail your formula is barely legible. Wouldn't it be easier to "typeset" it
in ascii?
Cheers,
Stefano
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: enhancement request: support biblatex
On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=584063 > > Seems fedora is not shipping biber, it is still an open bug > > You can always install it from their site, if you are willing to bypass Fedora's package management system: http://biblatex-biber.sourceforge.net/ Cheers, S. -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: enhancement request: support biblatex
On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker wrote: > stefano franchi wrote: > > > On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker > wrote: > > > >> I have read that biblatex is the way of the future. Unfortunately, I > >> understand > >> that lyx does not currently support biblatex. > >> > > > > Lyx supports biblatex *partially*. You can use biblatex in lyx with a few > > workarounds, all detailed in the corresponding wiki page: > > http://wiki.lyx.org/BibTeX/Biblatex. > > > > In short, you have to load biblatex and the bib files manually in the > > preamble, and you have to enter a command in ERT in your text to instruct > > LyX to print out the list of references. You are still able to enter > > references through a dialog box as you would when using bibtex. In > > practical terms, using biblatex in lyx is not much different from using > > bibtex, at least if you use the standard styles and citing commands. > > Having full support would be great, but the current setup is more than > > usable. > > > > > > Cheers, > > > > Stefano > > > > > > > > Oh, thanks! > > One note. It seems biber is not supported at least on Fedora linux. > Fedora > ships texlive 2013. I can't seem to find any biber there, and from what > messages I found on google, I think maybe it's not maintained? I have used > biblatex using bibtex backend instead of biber. > > Biber is under active development, actually, and well maintained. I use the version distributed with TexLive 2013, which is now frozen at 1.8 (TexLive 2013 is frozen, since the TexLive 2014 is about to come out). I don't know how Fedora packages Texlive (I'm on Archlnux), perhaps it behaves like Debian/Ubuntu and splits it into several packages? In hat case you may be missing one of the extra packages. Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: enhancement request: support biblatex
On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker wrote: > I have read that biblatex is the way of the future. Unfortunately, I > understand > that lyx does not currently support biblatex. > Lyx supports biblatex *partially*. You can use biblatex in lyx with a few workarounds, all detailed in the corresponding wiki page: http://wiki.lyx.org/BibTeX/Biblatex. In short, you have to load biblatex and the bib files manually in the preamble, and you have to enter a command in ERT in your text to instruct LyX to print out the list of references. You are still able to enter references through a dialog box as you would when using bibtex. In practical terms, using biblatex in lyx is not much different from using bibtex, at least if you use the standard styles and citing commands. Having full support would be great, but the current setup is more than usable. Cheers, Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [LyX-Mentors-GSoC-2013] Draft of welcome message to accepted GSOC students
Welcome to LyX message sent to accepted students. Message to acceptable/rejected students to follow soon. Cheers, S. On Mon, Apr 21, 2014 at 12:44 PM, Richard Heck wrote: > On 04/21/2014 01:14 PM, stefano franchi wrote: > > Thanks Richard. > > But I am not sure what you mean by: > > > On Mon, Apr 21, 2014 at 11:07 AM, Richard Heck wrote: > >> >> Captialize what follows. >> >> >> congratulations on your successful application to the Google's Summer >> of Code program and a hearty welcome to the LyX community from all of the >> developers. >> >> > Do you mean: > > 1. I forgot to capitalize "congratulations"; > > > Yes. > > rh > > -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Word to Lyx Converter
Hi Sean,
thanks for sharing your work with the list. As you may know already
from some recent exchanges on the devel list, we are exploring some options
that we hope will eventually take us to the promised land of a LyX<-->Word
roundtrip converter. I have started some ---very---preliminary work in the
area in the last few weeks, mostly trying to plot a feasible strategy
around a rather complex problem.
I haven't done any concrete coding in the area, but my favorite strategy
for the Word-->LyX step would tend to lean toward a direct parsing of the
XML format produced either by Word (the docx format) or by
{Open|Libre}Office (the odt format), possibly directly into LyX (avoiding
the LaTeX intermediate step).
I would be very interested in knowing your thoughts on the issue and the
reasons that prompted you to choose a rtf2latex+perl solution.
Cheers,
Stefano
On Sat, Apr 5, 2014 at 3:28 PM, Sean Patrick Burke wrote:
> Hi everybody.
>
> I know we’ve been down this road a bunch of times but I think a Word
> (doc/docx) converter to lyx would be really useful. I’ve written one in
> perl and attached it for the list to tear apart. If the group likes it,
> maybe we can stick in a future version. Continue on for details.
>
> Dependencies
> The script relies on LibreOffice and rtf2latex2e. I’ve fatpacked the
> script so it should run on any default perl installation. I’ve tested it on
> linux (Ubuntu13.10) and OS X Mavericks. I don’t have access to a Windows
> box, but obviously that would be a useful extension.
>
>
> Usage
> At the command line:
> word2lyx.pl —in myfile.doc —out yourfile.lyx [—verbose —debug —ugly]
>
> In lyx:
> Set up a standard converter (“MS Word” and “Lyx”). The call is:
> perl $$s/word2lyx.pl --in $$i --out $$o
>
> Note: “MS Word” only looks for .doc files as a default, but the script
> works with both .docx and .doc.
>
> How to Convert Most Word Files to Lyx
> This is convoluted, but it works in most cases. In brief:
>
> (Docx|Doc) -> Word 97 Doc -> Fix LibreOffice Footnote Bug -> RTF -> Latex
> -> More clean-up -> Lyx
>
> rtf2latex2e seems to choke on modern Word files, so regardless of the
> input you need to convert the document to a Word 97 doc. If you go from
> input straight to rtf, rtf2latex2e will melt down in some cases.
>
> Generically, the commands in the chain are:
>
> Modern Doc -> Paleo Doc
> soffice --headless --convert-to doc:"MS Word 97" --outdir /tmp my_input_doc
>
> Paleo Doc -> RTF
> soffice --headless --convert-to rtf:"Rich Text Format" --outdir /tmp
> my_paleo_doc
>
> At this point, we have to go in and correct an unreported footnote bug in
> the LibreOffice’s RTF converter. It’s not worth going into here. Email me
> if you want details.
>
> RTF->Latex
> rtf2latex2e -n -p 33 -t 12 my_rtf
>
> Clean up step. For some reason tex2lyx chokes on an unescaped ampersand
> (the kind that are generated when one is inserted in a Word file). I also
> usually cut out the well meaning (but ugly) custom spacing. (You can turn
> this off by adding —ugly to the above command line.)
>
> Latex->Lyx
> tex2lyx my_tex
>
> Anyway, I’ve tested it on a dozen or so varying word files on Lyx 2.0.6.
> The output isn’t pretty, but footnotes and basic formatting is usually
> preserved.
>
> I’d love input if any is available.
>
> Attachments: word2lyx.pl (without modules included),
> word2lyx.packed.0.99.pl (with modules).
>
> Best,
>
> Sean Burke
>
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Testing formulas in docx/odt
Does anyone have a Microsoft Word and/or LIbreOffice document with sufficiently complex math that they would be willing to share? I wold like to conduct some tests on the portability of formulas from Libreoffice to Word and viceversa, in the context of a LyX-->Word exporter. The formulas should have been natively written in Word/LibreOffice (with their respective equation editors) and not exported from LaTeX (via, e.g., latex2rtf or similar tools). Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Fwd: OPW
-- Forwarded message -- From: Αποστολίδου Χρυσαφή Date: Mon, Mar 17, 2014 at 5:12 AM Subject: Re: OPW To: stefano franchi Hi I thinkj that your icons are too good to be changed. Anyway If you ever need some design work to be done please feel free to ask me if i can do it. Have a nice day and thanks for your kind reply On Tue, Mar 11, 2014 at 3:14 PM, stefano franchi wrote: > > On Tue, Mar 11, 2014 at 1:58 AM, Αποστολίδου Χρυσαφή > wrote: > > Hi > > OPW is Outreach Program for Women > > https://wiki.gnome.org/OutreachProgramForWomen#Send_in_an_Application > > Its about internships for women working at free and open source > > organizations. > > > > If a woman want to apply she has to contribute first. > > I found your request at > > https://wiki.gnome.org/Initiatives/GnomeGoals/HighResolutionAppIcons > > My mentor asked me to contribute some art/design work to someone at this > > list. > > > > So, if you need some help with art/design i could do some work for you. > > > > Have a nice day > > Hi Hrisafi, > > thank you for providing some additional info about OPW. I was not > aware that Gnome had listed LyX as in need of graphic work. But they > are nonetheless correct that we would benefit from a high res > application icon for Gnome's (as we as others') desktop. > We would welcome contributions by a talented artist, none of the > developers has any background in the graphic arts. > > Not being a graphic designer myself, I am not really sure which kind > of input from us you would need to get you started. Our existing icons > can be seen here: > http://wiki.lyx.org/LyX/Icons > > As you can see we basically have two themes, an "all letters" one and > a "letter plus bird" one. That's all I can think of now. Feel free to > bug me with more questions if needed. > > Cheers, > > Stefano > > -- > __ > Stefano Franchi > Associate Research Professor > Department of Hispanic Studies Ph: +1 (979) 845-2125 > Texas A&M University Fax: +1 (979) 845-6421 > College Station, Texas, USA > > stef...@tamu.edu > http://stefano.cleinias.org -- - ZiZ | INTERNET SERVICES Official Greek Registrar (.gr) - 9 Edmondou Rostan Str. | Thessaloniki 54641 GR Τ. +30.231.3044823, +30.6983 746 147, T. +30.6947 309 020 F. +30.231.3044823 | URL: http://ziz.gr Client Area: http://billing.ziz.gr -- -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Request for mentoring for in Google Summer of Code 2014
On Mon, Mar 17, 2014 at 1:19 PM, Richard Heck wrote:
> On 03/17/2014 02:07 PM, Mitul Modi wrote:
>>
>> On 3/10/14, Vincent van Ravesteijn wrote:
>>>
>>> Hi Mutil,
>>>
>>> I would indeed like to mentor this kind of project. As my colleagues
>>> on the list suggested, it would be good if you could submit some code
>>> fixing little bugs, or you could propose what you think what would be
>>> needed for fixing the 3-box inset problem.
>>>
>>> See you on LyX-devel.
>>>
>>> Vincent
>>>
>> Hello Vincent van Ravesteijn sir,
>>
>> Are you going to mentor this project in GSoC 2014 as you have told
>> that you would like to do it. But I am confused as I haven't got any
>> further reply for my mails and patch from you. As Student Application
>> deadline is just 4 days away, please give me reply.
>
>
> Mentors don't officially get assigned until Google tells us how many slots
> we have and we decide which applications we'd like to accept. If I remember
> correctly.
Prospective mentors can ask to be assigned ("Wish to mentor") to any
officially submitted proposal.
For a small org like ours, this will have no effect until we receive
slots and have completed our assessment.
I guess it may be different for big orgs with tens and tens of slots (i.e. KDE)
S.
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Math in LibreOffice/Word exported files: input needed
Dear LyX devels and users, an issue has come up in our current efforts to produce a reliable LibreOffice exporter/converter from LyX that concerns how to export mathematical expressions. We need some user input and common use cases to make sensible design choices. Feel free to skip the technical details below and jump directly to the questions at the end, if you want. ==PROBLEM== Here is the problem: We can export a math expression to a LibreOffice/ODt file as MathML (there are still issues, but assume for the moment that the export will be perfect). However, LIbreOffice's supports only a limited subset of the MathML standard, and does not even use such MathML internally (it uses a format called StarMath that resembles very much the troff/eqn format but is much less expressive, for those who are interested in this kind of things). Moreover, LibreOffice uses the "Semantic" version of MathML, whereas the exporter uses the "Presentation" version, which further complicates issues. We are thus faced with a design choice: 1. Leave the exporter as it is and be left with imperfect and sometimes incomplete but editable math expressions when LaTeX is used at its fullest 2. Instruct the exporter to produces images of math expressions instead of MathML, and leave the job to create a perfect-looking math expression in LibreOffice/Word to the publisher/typesetter. Notice that in either case we could store the original LaTeX expression in the XML file for further processing (for instance for a return conversion to LyX). The choice between (1) and (2), in my opinion, depends on the most common use cases. A. If the "consumer" of an exported word file is a publisher and the mathematical expressions are complicated, then option (2) seems more reasonable. LibreOffice intrinsic limitations makes it very difficult if not impossible to produce a satisfactory, editable formula from a complex LaTeX expression. B. On the other hand, if the math expressions are relatively simple, then aiming for editable formulas may be an achievable goal C. Finally, if the "consumer" is a colleague with whom you collaborate, (2) seems to make more sense: editing will be carried out on the LyX/LaTeX side. === QUESTIONS So the questions are: 1. Are you a potential user of a Word/LibreOffice export converters? 2. If so, do you use routinely use mathematical expressions in your documents? 3. Why do you/would you need to export to LibreOffice/Word format? (to send the documents to publishers, mentors, advisors, colleagues, and so on) == Feedback welcome!! Cheers, Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Error : KOMA-script Book requires external files
On Thu, Mar 13, 2014 at 9:40 AM, Ankit Shah wrote:
>
>
>
> On Thu, Mar 13, 2014 at 7:13 PM, stefano franchi
> wrote:
>>
>> On Thu, Mar 13, 2014 at 6:24 AM, Ankit Shah
>> wrote:
>> > I cloned the LyX repository and ran ./autogen.sh ./configure and make.
>> > I'm
>> > using Ubuntu Gnome 13.10. After installing when i try to open User Guide
>> > or
>> > any other document I get the following errors:
>> >
>> > The selected document class
>> > KOMA-Script Book
>> > requires external files that are not available.
>> > The document class can still be used, but the
>> > document cannot be compiled until the following
>> > prerequisites are installed:
>> > scrbook.cls
>> > See section 3.1.2.2 (Class Availability) of the
>> > User's Guide for more information.
>> > Warning: Package not available
>> >
>> > The module customHeadersFooters requires a package that is not
>> > available in your LaTeX installation, or a converter that
>> > you have not installed. LaTeX output may not be possible.
>> > Missing prerequisites:
>> > fancyhdr.sty
>> > See section 3.1.2.3 (Modules) of the User's Guide for more information.
>> > Warning: Package not available
>> >
>> > I have installed texlive and also did sudo apt-get build-dep lyx. Please
>> > guide as to what more and from where do I need to install the remaining
>> > stuffs.
>>
>> Hi Ankit,
>>
>> the scrbook.cls class and the fancyhdr.sty package are standard
>> packages in the TeXLive distribution. You should already have them on
>> your hard drive. One of the following things may have gone wrong:
>>
>> 1. You installed TeXLive *after* you installed LyX.
>> LyX still thinks you don't have a working installation and chokes.
>> Solution: Reconfigure LyX (Tools>>Reconfigure) and restart LyX.
>>
>>
>> 2. Your TexLive installation is incomplete.
>> This is possible (although scrbook.cls is one of the basic classes)
>> and Ubuntu's support of TeXLive leaves much to be desired. Check your
>> installation by compiling the sample file (sample2e.tex) it provides
>> from the commands line. In the standard texlive this file is at
>> /usr/local/texlive/2013/texmf-dist/tex/latex/base/sample2e.tex
>> Ubuntu may have put it somewhere else. You may also want to check the
>> scrbook class (just edit the sample23.tex file and change
>> \documentclass{article} to \documentclass{scrbook}
>>
>> 3. Finally, there may a problem with your paths, especially if you
>> launch lyx from a desktop utility instead of from the command line. In
>> LyX, Tools>>TeX Information should show you where LyX thinks your
>> classes and style files are (tick the "Show path" check box).
>>
>>
>> Hope it helps,
>>
>> Stefano
>>
>>
>>
>>
>> > --
>> > Ankit Shah
>>
>>
>>
>> --
>> __
>> Stefano Franchi
>> Associate Research Professor
>> Department of Hispanic Studies Ph: +1 (979) 845-2125
>> Texas A&M University Fax: +1 (979) 845-6421
>> College Station, Texas, USA
>>
>> stef...@tamu.edu
>> http://stefano.cleinias.org
>
>
>
> Using reconfigure the KOMA script error was removed, but a new error now
> comes when I open User Guide document regarding enumitem.sty
>
>
> Warning: Package not available
>
> The module enumitem requires a package that is not
>
> available in your LaTeX installation, or a converter that
> you have not installed. LaTeX output may not be possible.
> Missing prerequisites:
> enumitem.sty
>
> See section 3.1.2.3 (Modules) of the User's Guide for more information.
>
> I checked section 3.1.2.3 and navigated to Document>Settings but didn't find
> any module link for enumitem.sty.
> --
This may be a problem with Ubuntu's management of the TeX
installation. Did you use Ubuntu's Tex (via apt-get) or TeXLive's own
installation? In the former case, you probably need some additional
Ubuntu packages. Looks for something called tex-extra or perhaps
latex-extra (I am sorry I cannot be more precise, but I'm on Arch, not
on Ubuntu)
Stefano
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: Error : KOMA-script Book requires external files
On Thu, Mar 13, 2014 at 6:24 AM, Ankit Shah wrote:
> I cloned the LyX repository and ran ./autogen.sh ./configure and make. I'm
> using Ubuntu Gnome 13.10. After installing when i try to open User Guide or
> any other document I get the following errors:
>
> The selected document class
> KOMA-Script Book
> requires external files that are not available.
> The document class can still be used, but the
> document cannot be compiled until the following
> prerequisites are installed:
> scrbook.cls
> See section 3.1.2.2 (Class Availability) of the
> User's Guide for more information.
> Warning: Package not available
>
> The module customHeadersFooters requires a package that is not
> available in your LaTeX installation, or a converter that
> you have not installed. LaTeX output may not be possible.
> Missing prerequisites:
> fancyhdr.sty
> See section 3.1.2.3 (Modules) of the User's Guide for more information.
> Warning: Package not available
>
> I have installed texlive and also did sudo apt-get build-dep lyx. Please
> guide as to what more and from where do I need to install the remaining
> stuffs.
Hi Ankit,
the scrbook.cls class and the fancyhdr.sty package are standard
packages in the TeXLive distribution. You should already have them on
your hard drive. One of the following things may have gone wrong:
1. You installed TeXLive *after* you installed LyX.
LyX still thinks you don't have a working installation and chokes.
Solution: Reconfigure LyX (Tools>>Reconfigure) and restart LyX.
2. Your TexLive installation is incomplete.
This is possible (although scrbook.cls is one of the basic classes)
and Ubuntu's support of TeXLive leaves much to be desired. Check your
installation by compiling the sample file (sample2e.tex) it provides
from the commands line. In the standard texlive this file is at
/usr/local/texlive/2013/texmf-dist/tex/latex/base/sample2e.tex
Ubuntu may have put it somewhere else. You may also want to check the
scrbook class (just edit the sample23.tex file and change
\documentclass{article} to \documentclass{scrbook}
3. Finally, there may a problem with your paths, especially if you
launch lyx from a desktop utility instead of from the command line. In
LyX, Tools>>TeX Information should show you where LyX thinks your
classes and style files are (tick the "Show path" check box).
Hope it helps,
Stefano
> --
> Ankit Shah
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: GSoC: Overhauling LyX's converter scheme
On Tue, Mar 11, 2014 at 4:10 AM, Roy Xia wrote: > Hi everyone, > > So I've been studying the converter scheme in pursuit of the aforementioned > project suggestion. I've been mostly focusing on the particular changes > mentioned in the explanation on the wiki page; that is, to consolidate > output formats under one extension type but use qualifiers to distinguish > output format variants from one another, and to also refactor the converter > code to handle latex flavors more elegantly. I suppose my first question to > you all is whether there are any alternative suggestions or additional goals > out there for overhauling the converter scheme. > > I've also been studying the source code, gathering ideas on how the overhaul > might be implemented. As far as consolidating "variant" output formats, I > suspect that for the most part the actual conversion code will remain the > same, but a.) functionality for parsing and recognizing qualifiers will need > to be added, and b.) the path-finding algorithm for finding the shortest > chain will probably need to be somewhat modified to first search for output > formats with the desired qualifier and then search for the generalized > output format. I also suspect that the path-finding algorithm will be > further complicated by the presence of multiple flags; for example, I have > noticed that pdf7 (PDF cropped) is not labeled as a vector graphics format > whereas other pdf variants are, so if the pdf extension is to be > consolidated I suspect that vector graphics format will also have to become > a qualifier of some sort. In that sense, there may need to be some judgement > on which converter chain to use if, for example, the search only results in > two valid paths, one with qualifier A but not B, and another with qualifier > B but not A. All said and done though I'm not an expert on the converters, > so perhaps someone could shed some light on other considerations or critique > my analysis of the task at hand. > > As for dealing with the latex flavors, within the context of the converter > it seems they aren't used for much aside from generating log and aux > files--in fact, unless I missed something, the different flavors only differ > from one another by which program they use to generate those files, and the > current code seems to determine that program solely from the command > associated with the converter anyway. My gut instinct says to just have a > general "latex" flag set for each of these formats and automatically > determine the proper program to call from there without knowing what > specific type of latex it is, but since I'm not that experienced with latex > or any of its flavors I'm not sure if that's the right approach. Again > perhaps someone could shed more light on this subject for me, or make sure > my thinking isn't totally off track. Keep in mind that the three major TeX engines (pdftex, xetex, luatex) have some substantial differences that sometimes (indeed, often) make it impossible to compile the same Lyx file on some of them. Example: if a LyX file uses system-wide fonts instead of LaTeX font, then only XeTeX and LuaTex can be used. Viceversa, if a file contains figures/diagrams produces with pstrick commands, then Luatex (and possibly Xetex, I am not sure) cannot be used. Theses are just two examples, there are others. The bottom line is that often the choice of the TeX engine is constrained by the Latex commands and packages used in the Lyx document. Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Fonts issues when exporting to Word/ODT
On Mon, Mar 10, 2014 at 9:21 AM, stefano franchi wrote: > On Mon, Mar 10, 2014 at 2:43 AM, Guenter Milde wrote: >> On 2014-03-10, stefano franchi wrote: >>> Question for the LaTeX font experts: >> >>> Is there a *single* font family that contains enough glyphs to cover >>> Latin scrpts plus European diacritics and Greek and Cyrillic and can >>> be used with DVI output? >> >> CM. If you install CM-Super and the CB-Greek fonts or define substitutes. >> >> Actually, as this are more than 280 glyphs, no single 8-bit font file >> could be used. Instead, you must use the "fontenc" package and suitable font >> encodings. This also means you are free to combine font families "at will". >> See the substitutefont package for examples. >> http://www.ctan.org/pkg/substitutefont > > Hi Guenter, > > thanks for the info about cm-super. I had already given a quick look > at your substitutefont package > but I am not sure I can use it with the required setup. > > In particular, it seems fontenc has some serious issues with tex4ht > and should be avoided. > > So I guess the answer to my question is simply: "It can't be done" > Or better: > "Such a wide glyph coverage can only be obtained by either: > 1. using fontenc (and perhaps your substitutefont) and switching > between different sets of more limited fonts, or > 2. having direct access to a wide coverage OTF font either directly > through XeTeX low-level font commands or through the higher level > fontspec package" > > Since neither option seems to be supported out of the box by tex4ht, I > guess my focus should now revert back to the latter. Just to (provisionally ) close this issue: I just learned that supporting multiscript is indeed one of the biggest open issues on the tex4ht (my ignorance of this system is slowly decreasing, but I have yet to fully understand it). For future reference: 1. An excellent discussion of how to bring current tex4ht to cope with the full range of unicode points is contained in this thread on the tex4ht list: http://tug.org/pipermail/tex4ht/2013q1/000719.html The thread discusses various workarounds (including perl processing of the latex file to carry out unicode substitution) and one of of them apparently allowed a grad student to write a dissertation that included standard European diacritics, Greek, Arabic and Syriac. That's quite a high threshold, in my opinion. 2. Michal Hoftich has provided a proof of concept [1] of an alternative approach that actually looks even more promising in the long term. It relies on luatex and its ability to post-process the tex nodes directly in Lua. As far as I understand it, his approach eliminates the step of tex4ht that relies on DVI files and allows full use of fontspec and, therefore, of standard OTF fonts. I am not sure how much work would be needed to extend his proof of concept to the full range of features we'd like in the Lyx-->Word export, but I'm looking into it. My hope is that the work needed to support the current tex4ht processor will carry over into to a more powerful (font-wise) lua4ht setting. Cheers, Stefano [1] https://github.com/michal-h21/lua4ht > > > Thanks for the help. > > Stefano > > -- > __ > Stefano Franchi > Associate Research Professor > Department of Hispanic Studies Ph: +1 (979) 845-2125 > Texas A&M University Fax: +1 (979) 845-6421 > College Station, Texas, USA > > stef...@tamu.edu > http://stefano.cleinias.org -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Python problems on windows - some debugging hints
On Mon, Mar 10, 2014 at 9:37 AM, Vincent van Ravesteijn wrote: > On Mon, Mar 10, 2014 at 3:28 PM, stefano franchi > wrote: >> On Mon, Mar 10, 2014 at 8:40 AM, Vincent van Ravesteijn wrote: >>>> >>>>>> The last days I spent some time to update the >>>>>> installer for LyX 2.1 and if that is allowed, I would release a third >>>>>> beta of LyX 2.1 to have a chance to get feedback for the installer >>>>>> itself. Can I do that? >>>>> >>>>> >>>>> We will hopefully have a new beta or release candidate soon. >>>> >>>> >>>> A new beta release would be very helpful. I think I am almost ready with >>>> the >>>> installer for LyX 2.1 (only thesaurus dictionaries don't work yet). >>>> However, LyX2.1 as it is at the moment is not really usable: >>>> While working on the docs, I get a crash each half an hour and I am not >>>> able >>>> to give a crash recipe. It crashes either when pressing Ctrl+C or Ctrl+V - >>>> but LyX crashes immediately without any debug output. >>>> >>> >>> >>> Well, that would be very bad if LyX 2.1 is still not usable. >> >> >> I just installed the latest 2.1-dev and I get a crash right away on >> the test document I have for the Lyx-->Word export whenever I try to >> compile. >> This is the last bit of the console output when Lyx is launched in debug >> mode: >> >> TextMetrics.cpp (1420): examining: pit: 3 y: 341 >> lassert.cpp (TextMetrics.cpp43 (1420): examining: pit: 4 y: 367 >> ): TextMetrics.cpp (1420): examining: pit: 5 y: 393 >> ASSERTION TextMetrics.cpp (1420): examining: pit: 6 y: 419 >> id < (int)authors_.size() VIOLATED IN Author.cpp:TextMetrics.cpp122 ( >> Assertion triggered in 1420void lyx::doAssert(const char*, const >> char*, long int)): by failing check "examining: pit: false7" y: in >> file 445lassert.cpp >> :TextMetrics.cpp45 ( >> 1420): examining: pit: 8 y: 471 >> TextMetrics.cpp (1420): examining: pit: 9 y: 497Aborted (core dumped) >> > > Did you use the Compare functionality to create this document ? > Not sure what you mean. The file was created in 2.0.7, then loaded into Lyx 2-1-dev. Actually it is "files" rather than "file" For ease of testing the various features we would like to work in the export, I created a master document with 14 small child documents on single issues. All the files (including the bib and images support files) are on this public repo: https://sfran...@bitbucket.org/sfranchi/lyxtowordandback.git I have troubles with two files: 1. the master file: GSOC2014-LyX-Word-roundtrip-tests.lyx 2. and the child file containing bits in different languages including Polytonic Greek and Russian: GSOC2014-LyX-Word-roundtrip-Multilanguage-texts.lyx In both cases I get a crash. All files compile fine in 2.0.7 (with xetex) Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Python problems on windows - some debugging hints
On Mon, Mar 10, 2014 at 8:40 AM, Vincent van Ravesteijn wrote: >> >>>> The last days I spent some time to update the >>>> installer for LyX 2.1 and if that is allowed, I would release a third >>>> beta of LyX 2.1 to have a chance to get feedback for the installer >>>> itself. Can I do that? >>> >>> >>> We will hopefully have a new beta or release candidate soon. >> >> >> A new beta release would be very helpful. I think I am almost ready with the >> installer for LyX 2.1 (only thesaurus dictionaries don't work yet). >> However, LyX2.1 as it is at the moment is not really usable: >> While working on the docs, I get a crash each half an hour and I am not able >> to give a crash recipe. It crashes either when pressing Ctrl+C or Ctrl+V - >> but LyX crashes immediately without any debug output. >> > > > Well, that would be very bad if LyX 2.1 is still not usable. I just installed the latest 2.1-dev and I get a crash right away on the test document I have for the Lyx-->Word export whenever I try to compile. This is the last bit of the console output when Lyx is launched in debug mode: TextMetrics.cpp (1420): examining: pit: 3 y: 341 lassert.cpp (TextMetrics.cpp43 (1420): examining: pit: 4 y: 367 ): TextMetrics.cpp (1420): examining: pit: 5 y: 393 ASSERTION TextMetrics.cpp (1420): examining: pit: 6 y: 419 id < (int)authors_.size() VIOLATED IN Author.cpp:TextMetrics.cpp122 ( Assertion triggered in 1420void lyx::doAssert(const char*, const char*, long int)): by failing check "examining: pit: false7" y: in file 445lassert.cpp :TextMetrics.cpp45 ( 1420): examining: pit: 8 y: 471 TextMetrics.cpp (1420): examining: pit: 9 y: 497Aborted (core dumped) Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Fonts issues when exporting to Word/ODT
On Mon, Mar 10, 2014 at 2:43 AM, Guenter Milde wrote: > On 2014-03-10, stefano franchi wrote: >> Question for the LaTeX font experts: > >> Is there a *single* font family that contains enough glyphs to cover >> Latin scrpts plus European diacritics and Greek and Cyrillic and can >> be used with DVI output? > > CM. If you install CM-Super and the CB-Greek fonts or define substitutes. > > Actually, as this are more than 280 glyphs, no single 8-bit font file > could be used. Instead, you must use the "fontenc" package and suitable font > encodings. This also means you are free to combine font families "at will". > See the substitutefont package for examples. > http://www.ctan.org/pkg/substitutefont Hi Guenter, thanks for the info about cm-super. I had already given a quick look at your substitutefont package but I am not sure I can use it with the required setup. In particular, it seems fontenc has some serious issues with tex4ht and should be avoided. So I guess the answer to my question is simply: "It can't be done" Or better: "Such a wide glyph coverage can only be obtained by either: 1. using fontenc (and perhaps your substitutefont) and switching between different sets of more limited fonts, or 2. having direct access to a wide coverage OTF font either directly through XeTeX low-level font commands or through the higher level fontspec package" Since neither option seems to be supported out of the box by tex4ht, I guess my focus should now revert back to the latter. Thanks for the help. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Fonts issues when exporting to Word/ODT
On Mon, Mar 10, 2014 at 1:16 AM, Liviu Andronic wrote:
> On Mon, Mar 10, 2014 at 6:15 AM, stefano franchi
> wrote:
>> Question for the LaTeX font experts:
>>
>> Is there a *single* font family that contains enough glyphs to cover
>> Latin scrpts plus European diacritics and Greek and Cyrillic and can
>> be used with DVI output?
>>
>> Background:
>>
>> - The Word-export strategy I am exploring in some depth goes through
>> tex4ht, which relies on DVI. Although it is compatible with xelatex
>> and hence (I think) unicode input file, it is not compatible with the
>> fontspec package. Hence only LaTeX fonts can be used.
>>
>> - I am testing the export of a simple multi-language file that
>> includes bits in Greek polytonic and Russian (plus other European
>> languages) and I am trying to find a single font covering all of the
>> above, so we can get the relevant characters over into Word/ODT(where
>> they may be changed at will).
>>
>
>
>> - I thought Linux Libertine could fit the bill, as it is known to have
>> a very wide coverage. Unfortunately it could not get it to play nice
>> with tex4ht.
>>
> Did you use \usepackage{libertine}, for the LaTeX font?
> http://www.ctan.org/pkg/libertine
>
>
I did. That's what I meant when I said that I tried Linux Libertine.
But the libertine package (which works flawlessly when used with
standard XeTeX)
gives me a lot of errors when used with tex4ht
> Also, have you tried cm-lgc – Type 1 CM-based fonts for Latin, Greek
> and Cyrillic?
> http://www.ctan.org/tex-archive/fonts/ps-type1/cm-lgc/
>
I haven't tried these, thanks for the pointer. From a quick look at
the README file, I suspect they are not what I need, since they
involve the use of the whole virtual font machinery that I was trying
to avoid.
But I need to read more on XeTeX use without fontspec. I am probably
misunderstanding somethig basic about its dealing with fonts.
Stefano
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Re: OPW
On Mon, Mar 10, 2014 at 7:15 AM, Αποστολίδου Χρυσαφή wrote: > Hi > > My name is Hrisafi and i am designer. > > I intent to send an aplication for the OPW and i want to make a > contribution. > > I work with inkscape, gimp, scribus and a little of blender. > > > Please let me know if you need some Art/design work to be done > Hi Hrisafi, thank you for your interest in LyX. I am afraid I am not familiar with OPW, though. Could you explain what is is about? Best, Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Fonts issues when exporting to Word/ODT
Question for the LaTeX font experts: Is there a *single* font family that contains enough glyphs to cover Latin scrpts plus European diacritics and Greek and Cyrillic and can be used with DVI output? Background: - The Word-export strategy I am exploring in some depth goes through tex4ht, which relies on DVI. Although it is compatible with xelatex and hence (I think) unicode input file, it is not compatible with the fontspec package. Hence only LaTeX fonts can be used. - I am testing the export of a simple multi-language file that includes bits in Greek polytonic and Russian (plus other European languages) and I am trying to find a single font covering all of the above, so we can get the relevant characters over into Word/ODT(where they may be changed at will). - I thought Linux Libertine could fit the bill, as it is known to have a very wide coverage. Unfortunately it could not get it to play nice with tex4ht. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSOC 2014] - Implement 3-box drawing of insets
On Sun, Mar 9, 2014 at 1:16 AM, Mitul Modi wrote: > Hello sir, > > Extremely Sorry for delay in reply but I was busy with my academic > exams, but during this time I got familiar with Lyx and insets.I have > explored Lyx source code. I have taken bug(ticket : 8829) and will > submit patch soon. > As you told me to contact you after exploring code base and GSoC > Project application submission starts from tomorrow, I think it is > right time to discuss about project(Implement 3-box drawing of > insets). So if you can give more detail about project,it will be > helpful. > Hi Mitul, welcome back! There is a general description of the project on Lyx's GSOC 2014 web page. You mentioned that you are now familiar with Lyx's code for insets. Perhaps you could try to apply your newly acquired knowledge to the problem as described in the LyX page and suggests how you wold approach it? Then the people on the list can comment on your proposed strategy. Best, Stefano ___ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: biblatex and Lyx 2.1
On Sat, Mar 8, 2014 at 10:33 AM, Jürgen Spitzmüller wrote: > 2014-03-08 17:22 GMT+01:00 Richard Heck : > >>> I probably screwed up the install. How do you make a completely >>> parallel installation of Lyx 2.1 that won't touch the existing 2.0 >>> version either in the local dirs (the ~/.lyx folder) and in the global >>> tree (all the stuff installed under /usr)? >> >> >> If you're just testing, you don't need to install 2.1 at all. You can just >> run it from where you compile it. As for the userdir, just run it as: >> /path/to/2.1/src/lyx -userdir /home/you/lyx21/ >> or whatever. > > > And if you want to install, compile --with-version-suffix=-2.1 > This will install LyX as a lyx-2.1 binary, use a different installation path > /usr/local/lyx-2.1 for instance, and a different user directory (~/lyx-2.1 > in this case). Ok. This worked. Thanks. Unfortunately Lyx crashes on compiling the file... I will report further once I have a clearer idea why Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: biblatex and Lyx 2.1
On Sat, Mar 8, 2014 at 10:22 AM, Richard Heck wrote: > On 03/08/2014 11:14 AM, stefano franchi wrote: >> >> On Sat, Mar 8, 2014 at 9:57 AM, Jürgen Spitzmüller wrote: >>> >>> 2014-03-08 16:00 GMT+01:00 stefano franchi: >>> >>>> I am trying to convert to 2.1 the test document we will use for the >>>> lyx<-->word tests, and I am stuck on biblatex. >>>> The biblatex module we have for 2.0.* loads natbib: >>>> >>>> Format 11 >>>> >>>> # this is biblatex actually >>>> Provides natbib1 >>>> >>>> >>>> Lyx 2.1 complains that the natbib module cannot be found. >>> >>> >>> I also use this module and do not have this problem. Maybe your >>> installation >>> is not complete. You should have a module natbib.module in LyX's system >>> layouts/ folder. Maybe this is missing at your side? If not, we need >>> probably a bit more info. >>> >> I probably screwed up the install. How do you make a completely >> parallel installation of Lyx 2.1 that won't touch the existing 2.0 >> version either in the local dirs (the ~/.lyx folder) and in the global >> tree (all the stuff installed under /usr)? > > > If you're just testing, you don't need to install 2.1 at all. You can just > run it from where you compile it. As for the userdir, just run it as: > /path/to/2.1/src/lyx -userdir /home/you/lyx21/ > or whatever. That's exactly what I was doing. And it fails as described. I also just discovered it cannot find the memoir class, even though the "Tex information" shows it is there. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: biblatex and Lyx 2.1
On Sat, Mar 8, 2014 at 9:57 AM, Jürgen Spitzmüller wrote: > 2014-03-08 16:00 GMT+01:00 stefano franchi: > >> I am trying to convert to 2.1 the test document we will use for the >> lyx<-->word tests, and I am stuck on biblatex. >> The biblatex module we have for 2.0.* loads natbib: >> >> Format 11 >> >> # this is biblatex actually >> Provides natbib1 >> >> >> Lyx 2.1 complains that the natbib module cannot be found. > > > I also use this module and do not have this problem. Maybe your installation > is not complete. You should have a module natbib.module in LyX's system > layouts/ folder. Maybe this is missing at your side? If not, we need > probably a bit more info. > I probably screwed up the install. How do you make a completely parallel installation of Lyx 2.1 that won't touch the existing 2.0 version either in the local dirs (the ~/.lyx folder) and in the global tree (all the stuff installed under /usr)? S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
biblatex and Lyx 2.1
I am trying to convert to 2.1 the test document we will use for the lyx<-->word tests, and I am stuck on biblatex. The biblatex module we have for 2.0.* loads natbib: Format 11 # this is biblatex actually Provides natbib1 Lyx 2.1 complains that the natbib module cannot be found. What am I doing wrong? Is the format to blame? I tried to find an existing layout for 2.1 to modify but I don't see any in the lyx tree. Sorry for the silly question, it's been a while since I worked with development versions of lyx. Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Compilation issues on Arch
On Fri, Mar 7, 2014 at 12:56 AM, Stephan Witt wrote: > Am 07.03.2014 um 06:05 schrieb stefano franchi : > >> I just synced my local copy of the lyx repo and compilation now fails >> with Qt related issues. >> >> Here is the first error: >> >> [ 4%] Building CXX object >> src/support/CMakeFiles/support.dir/Systemcall.cpp.o >> cd /home/stefano/builds/lyx-devel/lyx/build/src/support && >> /usr/bin/c++ -DQT_CORE_LIB -Wall -Wunused-parameter >> -fno-strict-aliasing -Wall -Wunused-parameter -fno-strict-aliasing >> -O0 -g3 -D_DEBUG -fPIC -I/home/stefano/builds/lyx-devel/lyx/build >> -I/home/stefano/builds/lyx-devel/lyx/src >> -I/home/stefano/builds/lyx-devel/lyx/boost >> -I/home/stefano/builds/lyx-devel/lyx/src/support >> -I/home/stefano/builds/lyx-devel/lyx/build/src/support >> -I/home/stefano/builds/lyx-devel/lyx/src/support/mythes >> -I/usr/include/qt -I/usr/include/qt/QtCore >> -I/usr/lib/qt/mkspecs/linux-g++-DBOOST_USER_CONFIG="" -o >> CMakeFiles/support.dir/Systemcall.cpp.o -c >> /home/stefano/builds/lyx-devel/lyx/src/support/Systemcall.cpp >> In file included from >> /home/stefano/builds/lyx-devel/lyx/src/support/Systemcall.cpp:631:0: >> /home/stefano/builds/lyx-devel/lyx/src/support/moc_SystemcallPrivate.cpp:13:2: >> error: #error "This file was generated using the moc from 4.8.5. It" >> #error "This file was generated using the moc from 4.8.5. It" >> >> >> Isn't the build process still relying on Qt 4? The cmake build comes >> preset to use the moc from version 4 (Qt 4.8.5) (it looks in >> /usr/lib/bin/qt4/moc). Or perhaps is my system to blame? Arch defaults >> to QT5. > > moc_SystemcallPrivate.cpp has been generated by a call to the moc found by > LyX's configure. > I'm not sure - you have to look up the logs of your build - possibly it's > called with > moc4 because both versions are installed or the moc binary is a Qt4 thing > somehow. > > But it's not a good idea to build LyX with Qt5, ATM. At least for Mac and > Windows builds. > I don't know if Linux has no problems. > Ok, that's what I wanted to know--I hadn't followed closely all the recent discussion about QT5 and I though may the build process had switched to it. I guess my problem is with my system then. QT5 must enter into the process at some point, and I'll have to fix that. On the plus side, I just tried compiled the automake way, and it works fine. I'll see if I can fix the cmake config file to avoid conflicts with QT5. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: GSoC Project: Advance find and replace
On Thu, Mar 6, 2014 at 11:12 PM, Sushant Raikar wrote: > Hi , > > I am Sushant Raikar ,a B.Tech. ( Computer Science ) student from India and I > would love to contribute to LyX (Project : Advance find and replace ) for > GSOC 2014. I have fair knowledge in Networking and I am pretty comfortable > with c++ and Qt. > I have worked on Qt project before, here's the link ( > http://www.youtube.com/watch?v=NVRA2ZbxDpI ). > > As for regular expressions , I know the basics of it but I wanted to know in > which context will it be used ( for example will it be used with QRegExp > class?) > > I might consider working for Project:Interactive Lyx as well. I have basic > knowledge of socket programming and have worked with remote connections > (http://www.youtube.com/watch?v=IG2jsOm6hJI) with TCP as well as UDP > packets. I wanted to know whether this knowledge is good enough for me to > work on this project. Hi Sushant, Welcome to LyX! The best way to get acquainted with the projects you are interested in is to start perusing the lyx-devel list and searching for the recent discussions on both topics. It would also be a good idea to get acquainted with LyX itself (and, to a lesser extent, LaTeX). If you are not a user, please install it on your system and start taking a look at the tutorial. That will give you an idea of the of the missing features the projects target (especially for the Adv Find and Replace). It would also be a very good to start getting acquainted with LyX code base, and a good way to do so is to look at our bug tracker [1] and search for bugs tagged "easyfix". Cheers! Stefano [1] http://www.lyx.org/trac/wiki/BugTrackerHome -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Compilation issues on Arch
I just synced my local copy of the lyx repo and compilation now fails with Qt related issues. Here is the first error: [ 4%] Building CXX object src/support/CMakeFiles/support.dir/Systemcall.cpp.o cd /home/stefano/builds/lyx-devel/lyx/build/src/support && /usr/bin/c++ -DQT_CORE_LIB -Wall -Wunused-parameter -fno-strict-aliasing -Wall -Wunused-parameter -fno-strict-aliasing -O0 -g3 -D_DEBUG -fPIC -I/home/stefano/builds/lyx-devel/lyx/build -I/home/stefano/builds/lyx-devel/lyx/src -I/home/stefano/builds/lyx-devel/lyx/boost -I/home/stefano/builds/lyx-devel/lyx/src/support -I/home/stefano/builds/lyx-devel/lyx/build/src/support -I/home/stefano/builds/lyx-devel/lyx/src/support/mythes -I/usr/include/qt -I/usr/include/qt/QtCore -I/usr/lib/qt/mkspecs/linux-g++-DBOOST_USER_CONFIG="" -o CMakeFiles/support.dir/Systemcall.cpp.o -c /home/stefano/builds/lyx-devel/lyx/src/support/Systemcall.cpp In file included from /home/stefano/builds/lyx-devel/lyx/src/support/Systemcall.cpp:631:0: /home/stefano/builds/lyx-devel/lyx/src/support/moc_SystemcallPrivate.cpp:13:2: error: #error "This file was generated using the moc from 4.8.5. It" #error "This file was generated using the moc from 4.8.5. It" Isn't the build process still relying on Qt 4? The cmake build comes preset to use the moc from version 4 (Qt 4.8.5) (it looks in /usr/lib/bin/qt4/moc). Or perhaps is my system to blame? Arch defaults to QT5. Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: About using git as file format for lyx ...
On Mar 6, 2014 8:09 PM, "Tommaso Cucinotta" wrote: > > ... instead of XML, as discussed so often ... > > https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV > > T. GSOC 2015? S.
Re: confirm subscribe to lyx-devel@lists.lyx.org
On Thu, Mar 6, 2014 at 3:07 PM, Tommaso Cucinotta wrote: > I thought to be subscribed to lyx-devel already. Anyone knows why I got this > message ? > I have been getting similar (non-identical) messages from both lyx-devel and lyx-users in the last couple of days. Apparently messages sent to me bounce back. Something wrong with the server perhaps? Stefano
test
test -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Update on discussions of LyX<-->Word export and round trip
On Tue, Mar 4, 2014 at 12:47 PM, Georg Baum wrote: > stefano franchi wrote: > >> That may be an option, but, as I mentioned, tex4ht project is very >> complex. I don't think it's a chance that the current maintainers, who >> are both Tex gurus with a deep knowledge of the structures tex4ht >> manipulates, have not released a new version after Eitan Guirari's >> passing in 2009. > > You are probably right, but another possible reason is that they simply have > plenty of other work to do. True. >> In short, this may be the only way to go for a full exporter, but it >> is a steep climb. > > I admit that I did not look into tex4ht in detail, so I trust your judgement > here. You shouldn't because I haven't looked at it in detail either... I have been discussing with Prannoy how to systematically investigate tex4ht from our own standpoint, so I may know more in the near future. > >> I agree with you here, even though, for the reasons discussed above, >> this point applies to the round-trip converter only. >> I think the XHTML approach gives more guarantees. And the LyX server >> may be an alternative. But reparsing the output of a process we >> control directly seems the wrong way to go. > > What do you mean with the last sentence? I am afraid I don't understand. At > least I did not want to suggest to parse some output generated by LyX. Sorry for the confusion. I was just trying to repeat your point, which I agree with: It makes little sense for LyX to parse its output (the .lyx file) when it has access to the process and data structures that generated it in the first place. Better? At any rate, we agree. I guess we can call this "The LyXHTML approach" to avoid further misunderstandings. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: GSoC Advance find and replace
Hi Mihai, We certainly remember you from last year interactions. Welcome back to LyX! Cheers, Stefano P. S. I'll leave the answer to your specific question to Tommaso, as he's best qualified to answer. On Tue, Mar 4, 2014 at 11:35 AM, Mihai Varga wrote: > Hello LyX community, > > My name is Mihai Varga, I am in my 2nd year of study at the Polytechnic > University of Bucharest and I am interested in the "Advanced find and > replace" project for GSoC. > > I do not know if some of you still remember me but I also applied last year > (but the project was not selected) and during the summer I have worked on > completing the project that I applied to. > > I have read Tommaso's post regarding this year's project's description and > I plan to have a look on what's already implemented. I would like to ask on > which branch could I find the code for this? > > Best regards, > Mihai -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Lyx-->Word and Lyx<-->Word: final agreement on projects' goals sought
Dear LyX devels, in light of all the recent discussions, my latest report, and the fact that GSOC 2014's application window is about to open (March 10), it'd be great if we could reach some consensus on the projects' goal and approaches. My current view of the matter is this: 1. We have two projects: export to Word and round trip conversion to be pursued independently 2. Export to Word requires LaTeX processing and is therefore best pursued with tex4ht and by adding/contributing to its own current functionalities. 3. Round trip conversion is best pursued by exporting directing to Word XML-based format from within LyX code (i.e. from the C++/Qt side) for the LyX-to-Word trip and with either C++/Qt or Python for the reverse Word-to-Lyx trip. N.B. "Word" stands for docx|odt throughout Comments welcome. Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Note on current limitations of tex4ht for LyX --> Word conversion
As further info on our current discussion of the LyX --> Word conversion, here are some of the problems I encountered over the weekend when converting a ~50,000 word lyx file that had the features detailed below. I will eventually make a wiki page with the information contained here, once I have a more stable and testable configuration. I was in a rush and did not have time to take detailed note of all the problems I ran into. The overall process took me about 12 hours, and it includes all the dead ends I ran into. If had to do it again tomorrow (God forbid!) , with the acquired knowledge, it would probably take me 1 hour for the conversions plus the time to redo the bibliography (see below). On afternoon in total, I think. Comments are welcome, and even more so reports on tex4ht use. I think contributing to the tex4ht project (as Georg suggested) is a valid option at this point, and I would like to put together a minimal set of features we would like to see fully supported. Manuscript details: Class: memoir Bibliography: Biblatex plus biber with custom style (biblatex-philosophy) Engine: XeTeX (originally it was LuaTex, but I switched to XeTeX later) Language: Italian, with some bib refs and a few fragments in other European languages (French, English, German) Encoding: UTF-8, bot for lyx/tex file and bib file Fonts: I did not really care (given the output), but I used the TeX Gyre family for their wide coverage. I struggled with different, often orthogonal problems, mostly focused on fonts/encoding/language, as reported below. In the end, the final but only partial solution was the following: 1. Switch to standard book class 2. Force the use of babel instead of polyglossia 3. Use biblatex standard styles 3. Do not print out the bibliography. This meant that I was eventually successful with the body text conversion (including the references in the text), but then I had to cut and paste the properly organized bibliography from the pdf file, and reformat manually, as all semantic formatting with such an operation (e.g. emphasis and small caps)). I tried both free and proprietary pdf-->word conversions with poor results. Most failed due to the encoding, I guess. Acrobat Pro succeeded, but the Word file it produced was of of such a poor quality that I quickly realized it would be faster to work from the text produced from the cut and paste. A word/libreoffice guru (which I am certainly not) may disagree on this. Main problems encountered in conversion: 1. Fonts/encoding tex4ht supports xetex, but not fontspec (an experimental version is available, but it is not even at alpha stage). It needs TeX fonts, not OTF. This limitation brought problems with Latin, non Ascii texts. Whereas XeTeX compilation with OTF version of TeX Gyre's family of fonts was flawless, the TeX version had issues with the guillemets and with the open single quote (apostrophe). I tried most ot the standard TEx fonts (cm, ecm, latin modern, and they all had similar issues (although not the *same* issues. That is, not always was the same character missing). 2. Language support - I had issues with the language support for Italian in one biblatex style (philosophy-modern, which is really the standard style for Italian publishing in general, not just in philosophy) - I could not get polyglossia to work. In the end I forced the use of babel 3. limited support for memoir. I actually could not compile with memoir and had to switch to the book standard class, which meant more reformatting in the final output. Memoir support is still very limited, a more comprehensive .4ht file should be provided 4. All too generous use of section breaks in output: tex4ht inserts block quotes in their own sections (in MS Word parlance). This causes a lot of problems: typically a new page break is enforced after a section break. I had to manually erase all the breaks. A custom tex4ht configuration file should take care of thsi problem, but I did not look into this any further. Stefano -- ______ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Update on discussions of LyX<-->Word export and round trip
On Mon, Mar 3, 2014 at 3:22 PM, Georg Baum wrote: > stefano franchi wrote: > >> (a) (Mimicking Latex) has the obvious problem that even once the basic >> LaTeX functionality is recovered, the LaTeX packages have to be >> basically recreated for the new engine. This is what happens in >> LaTeXML, where you have to write "bindings" fr every package you need >> to support. At the moment, many packages are not supported, including >> biblatex, and from the little I have seen on their mailing list adding >> such support is not trivial. >> On the plus side, since XML is the target, all the formatting-only >> machinery of TeX can be ignored (well, in theory. Real world is messy) > > IMHO writing "bindings" for packages is a huge disadvantage of this > approach. Also, parsing LaTeX is really a mess. I have yet to see a LaTeX > parser which covers enough functionality _and_ is understandable if you have > some LaTeX knowledge. IMHO there is a reason why so many projects of this > kind start and then get abandoned at some point of time. Absolutely. That's why running LaTeX itself seems a winning strategy. Howeverthe complexity of this approach is itself far from trivial, as the complexity of tex4ht testifies. > >> b. This approach has the advantage of bringing in support for all >> LaTeX packages for free. However, parsing a DVI file with the goal of >> producing XML is not trivial given the completely different design >> goals of DVI/vs/XMl > > Agreed, but what about contributing to tex4ht? According to > https://www.tug.org/tex4ht/ this would be welcome. That may be an option, but, as I mentioned, tex4ht project is very complex. I don't think it's a chance that the current maintainers, who are both Tex gurus with a deep knowledge of the structures tex4ht manipulates, have not released a new version after Eitan Guirari's passing in 2009. In those 5 years, tex4ht has fallen behind on a number of fronts, mainly Xe|LuaTex support and non-standard classes. Biblatex is supported, but not fully. I am fresh from another converting marathon, and I spent several hours fighting with the tex4ht/biblatex monster. In the end, I was able to convert the file and the citation, but not the references. Tex4ht would always choke while producing the bibliography (but not when processing the refs), probably due to a mixture of encoding and language problems (the book I was working on was in Italian, with an Italian-only biblatex style, and used UTF-8 tex and bib files). In short, this may be the only way to go for a full exporter, but it is a steep climb. > >> c. Finally, modifying an existing TeX engine (e.g. LuaTeX) may be the >> cleaner approach---at the price of much increased complexity. > > Yes, I guess this is probably too ambitious. > >> These seem to me to be the most important issues we face. I maybe >> forgetting some important points. If so, please correct me. >> Comments of any kind are welcome. > > Thanks for the nice summary. I'd like to add one point: If the converter > works on the .lyx file it must not only consider the already discussed > versioning problems, but also recreate parts of LyX, because the LyX file > itself does not carry all needed information. The missing bits are in the > layout machinery (i.e. the converter would need to read and understand lyout > files), and the format machinery (i.e. the converter would need to know > which file formats for images and included documents are defind and probably > also how to convert between them). Therefore I would personally prefer an > approach that either follows the existing xhtml export (i.e. implemented in > C++ in LyX itself), or is more loosely coupled via the LyX server. In both > cases it would reuse the layout and format knowledge of LyX without > problems. I agree with you here, even though, for the reasons discussed above, this point applies to the round-trip converter only. I think the XHTML approach gives more guarantees. And the LyX server may be an alternative. But reparsing the output of a process we control directly seems the wrong way to go. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Update on discussions of LyX<-->Word export and round trip
On Mon, Mar 3, 2014 at 3:17 AM, Rainer M Krug wrote: > stefano franchi writes: > >> Dear Lyx devels, > > Hi Stefano, > > thanks for a good summary of the discussion - I think you have > identified the main points. I have some comments below. > >> >> given the intense discussion we have had in the last few days on this >> possible project, I thought I would briefly sum up some of the early >> conclusions (also because some items were discussed in private >> emails). >> (BTW: In the following I say "Word" for the sake of brevity. I >> actually mean Word XML | Libreoffice ODT) >> >> 1. One project or two? >> >> Is a LyX-->Word export a subset of the LyX<-->Word roundtrip? >> >> A. If the final ouput is Word, the conversion to Word is a subset of >> the roundtrip *if and only if* the XML output preserve Lyx-only >> (non-LaTeX) information (e.g. tracked-changes, LyX-notes, etc). > > This point needs to be clarified: If one needs a semantic export, this > is true, as all semantic information needs to be maintained in the > round-trip as well as in the export. But not if the export should *look > like* the latex export. The limit in these discussions is semantics, and > not as much formatting (exceptions do apply, e.g. italics or bold of > words, which is important in articles which contain species names which > have to be in italics). > It should not. That is: a word-export conversion should *not* aim at preserving formatting. It should preserve the same (often formatting-encoded) semantic information of the round-trip converter. The only difference is that LyX has only pointers for some of these info (e.g. bibtes keys) and not the information itself. This is the major problem. (Additionally, some semantic LyX-provide semantic information could be shed by the exporter, such as tracked-changes and so on. But this is a minor problem). > Additionally: if it is a subset - perfect - but as in (B), the > round-trip does not have to include everything, as there could be a > semantic exporter. > >> >> B. If the final output is pdf, then it is not. It is not necessary to >> actually process the info in the .tex file with Latex (e.g >> bibliography,, and more). All we need to do is to make sure that the >> info that Latex will eventually need are preserved through the >> roundtrip. So, for a citation, we only need to make sure that when we >> go to Word we produce something like (made up XML): >> >>citet >> >> myBibkey >> >> >> >> and when we come back we reconstruct the proper LyX bib inset from >> those info. It will then be up to Latex to produce the actual citation >> and the corresponding reference. > > Agreed. > >> >> So scenario 2 is actually simpler, because we do not have a dependency >> on LaTeX at all. >> At the same time, scenario 1 is more important for those people who >> are likely to interact with Word users (see Juergen's comments, which >> I subscribe to). > > I would say to design the round-trip-export so that it can easily be > extended to become a fully fledged semantic exporter. > >> >> In general, then, we have overlapping projects with substantial >> differences sets: >> A - The LyX-only information that needs to be somehow encoded in the XML file >> B - The Latex-produced-only information that is missing from LyX >> >> Preserving LyX-only information in a XML file (A) strikes me as being >> substantially easier than producing the LyX-missing information (B) >> for the Word file. The latter requires TeX runs, the former does not. > > I assume you are here referring to the last A and B, as if I understand > correctly, the first definition of A and B is the opposite? Yes, Sorry, I switched them up. But the following refers correctly to the A and B options just mentioned. > > >> >> 2. How to produce a Word output, that is, how to solve problem B above? >> Since TeX is basically required to process a Lyx-produced tex file, >> the following approaches are available (there may be more than three, >> but these have known and working implementations): >> >> a. Mimic a TeX run by running a TeX-like processor on the tex file, >> but target XML as output >> examples: LatexML >> >> b. Run Latex and process the resulting Pdf or DVI file into XML >> examples: tex4ht >> >> c. Modify an existing Tex engine to target XML instead of pdf (or dvi) >> examples: XML from Context input in LuaTeX >> >> All three approaches are ambitious and have different shortcom
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
Hi Prannoy,
On Sun, Mar 2, 2014 at 10:56 AM, Prannoy Pilligundla wrote:
> I had a look at some recent posts on the Stack exchange and in LuaTex
> there is no package for LaTex to directly produce a XML.This is what we had
> expected but i still had some hope. So,the only way ahead was to write a
> module ourself. I spoke to one person in the LuaTex Developer mailing list
> via personal mails and he says that it can never be done by changes in the
> luatex engine and only way is to hook in some code via callbacks and it
> would demand some pretty large adaptions to the latex core code
> ᐧ
>
>
This is really not very good news, but thanks for looking into it. Thanks
also for the links to the other latex--> projects. It looks like going the
LuaTeX route is a no go. I think that for the export to word we really have
only two options:
1. Making htlatex work out of the box (which now it doesn't) for us, with a
custom configuration file narrowly tailored to our test document and
perhaps with the long term goal of replacing htlatex's complex processing
of the DVI file with a simpler (because more narrowly focused) processing
of our own.
2. Adding to latexml the pieces ("bindings," in their language) that would
be needed to support biblatex, memoir, and the custom, LyX-only
functionalities that we need (tracked changes, etc.).
I think solution 1 is much simpler (and more effective---we get LaTeX
processing for free)--- but potentially riskier: we'd be depending on
unmaintained code and eventually replacing it with our own is a large
undertaking.
Solution 2 has the advantage of relying on actively developed code but it
may not be a trivial effort to write "bindings" for LaTeXML. From what I've
seen, it comes close to rewriting the packages. Let's take a few more days
to look into these options, especially option 2 (which I know the least
about), before committing to a path.
There is also an option 3, of course, which is to abandon a LyX solutio for
the LyX-->Word export, and focus instead and the LyX<-->Word roundtrip.
Cheers,
Stefano
--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu
http://stefano.cleinias.org
Update on discussions of LyX<-->Word export and round trip
Dear Lyx devels, given the intense discussion we have had in the last few days on this possible project, I thought I would briefly sum up some of the early conclusions (also because some items were discussed in private emails). (BTW: In the following I say "Word" for the sake of brevity. I actually mean Word XML | Libreoffice ODT) 1. One project or two? Is a LyX-->Word export a subset of the LyX<-->Word roundtrip? A. If the final ouput is Word, the conversion to Word is a subset of the roundtrip *if and only if* the XML output preserve Lyx-only (non-LaTeX) information (e.g. tracked-changes, LyX-notes, etc). B. If the final output is pdf, then it is not. It is not necessary to actually process the info in the .tex file with Latex (e.g bibliography,, and more). All we need to do is to make sure that the info that Latex will eventually need are preserved through the roundtrip. So, for a citation, we only need to make sure that when we go to Word we produce something like (made up XML): citet myBibkey and when we come back we reconstruct the proper LyX bib inset from those info. It will then be up to Latex to produce the actual citation and the corresponding reference. So scenario 2 is actually simpler, because we do not have a dependency on LaTeX at all. At the same time, scenario 1 is more important for those people who are likely to interact with Word users (see Juergen's comments, which I subscribe to). In general, then, we have overlapping projects with substantial differences sets: A - The LyX-only information that needs to be somehow encoded in the XML file B - The Latex-produced-only information that is missing from LyX Preserving LyX-only information in a XML file (A) strikes me as being substantially easier than producing the LyX-missing information (B) for the Word file. The latter requires TeX runs, the former does not. 2. How to produce a Word output, that is, how to solve problem B above? Since TeX is basically required to process a Lyx-produced tex file, the following approaches are available (there may be more than three, but these have known and working implementations): a. Mimic a TeX run by running a TeX-like processor on the tex file, but target XML as output examples: LatexML b. Run Latex and process the resulting Pdf or DVI file into XML examples: tex4ht c. Modify an existing Tex engine to target XML instead of pdf (or dvi) examples: XML from Context input in LuaTeX All three approaches are ambitious and have different shortcomings. (a) (Mimicking Latex) has the obvious problem that even once the basic LaTeX functionality is recovered, the LaTeX packages have to be basically recreated for the new engine. This is what happens in LaTeXML, where you have to write "bindings" fr every package you need to support. At the moment, many packages are not supported, including biblatex, and from the little I have seen on their mailing list adding such support is not trivial. On the plus side, since XML is the target, all the formatting-only machinery of TeX can be ignored (well, in theory. Real world is messy) b. This approach has the advantage of bringing in support for all LaTeX packages for free. However, parsing a DVI file with the goal of producing XML is not trivial given the completely different design goals of DVI/vs/XMl c. Finally, modifying an existing TeX engine (e.g. LuaTeX) may be the cleaner approach---at the price of much increased complexity. 3. Should LyX<-->Word conversion be direct or use an intermediary format (e.g. pandoc | mmd | etc.)? This question applies mostly to the roundtrip project. The consensus seems to be that it would be better to avoid yet another format and go for direct conversion. On the minus side, such an approach would make it impossible (well, more difficult) to switch back-ends for the round trip, if so desired (see Rainer's points) These seem to me to be the most important issues we face. I maybe forgetting some important points. If so, please correct me. Comments of any kind are welcome. Cheers, Stefano -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
LyX<-->word --> Latex to XML
I just discovered the LaTeXtoXML project: http://dlmf.nist.gov/LaTeXML/ which is actively developed and may actually come very close to what we are aiming at. It is a perl-based attempt to recreate a subset of TeX with XML output. It is very math-oriented and, from a first look, not so bibliorgaphy oriented (although it does parse bibtex). did anyone know of it? I am going to try it on our test document and will report back on its current performance. In the meanwhile, if you have any reactions to such an approach, do not hesitate to share them. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
On Fri, Feb 28, 2014 at 10:49 AM, Rainer M Krug wrote: > Richard Heck writes: > >> On 02/28/2014 02:43 AM, Jürgen Spitzmüller wrote: >>> Am Donnerstag 27 Februar 2014, 12:29:36 schrieb stefano franchi: >>>> - Bibliography support with suitable styles is a must. This feature >>>> is as crucial to someone working in the Humanities, as math support >>>> is for >>>> someone working in the sciences. With the difference that scientists can >>>> often avoid conversion to Word, while Humanists just can't. >>> From my point of view (as someone being in the Humanities), this is >>> almost all that matters and the criterion that makes LyX -> Docx/ODT >>> conversion useful or completely useless for me. Everything else is >>> just a plus. >> >> Here, I think it's especially helpful to distinguish "round trip" >> conversion, which would be used during collaboration, from final >> export for publication. I take it that in the former case we just need >> to make sure not to lose bibliographic information. Only in the latter >> case do we need to be able to use or mimic biblatex, or whatever, to >> get the bibliographic information into some final form. > > Exactly - for round-trip, the format of the references is effectively > irrelevant, as long as one can see which ones they are, whereas for > export, the format is essential (not only for Humanities!). I would even > go so far and say that the inclusion of a properly formatted > bibliography in the round-trip would be causing more problems, as bibtex > et al only help on the one way - but how to get a new reference back > into LyX? So I would suggest to leave the citations in a basic format > (e.g. #+#bibtexID1,bibtexID2#+#) as a comment in the docx, so that they > can be seen. On the way back, #+#...#+# is then replaced by the citation > command in LyX, and if inside the #+# is not a valid bibtex id, it is > imported as a comment, which then can be interpreted by hand (could be a > new reference). Just to add food for thought: an option that would keep the full power of LaTeX (including our beloved bibliographies ;-)) would be to operate directly at the level of the teX compiler. Namely, LuaTeX. As far as I know, LuaTex already provides XML output when used with ConText, so it should be possible and perhaps not impossibly difficult (although certainly not easy). Or we could start supporting Context! S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: GSoC Student Application
Hi Jicksy, welcome to LyX! It's great to hear you are interested in the round trip conversion project. There is currently an intense and ongoing discussion about the project on the lyx-developers list. See [1]. That is a good starting point on the current state of the project and the various design decisions the developers are considering. As for getting familiar with LyX i ngeneral and with its code base in particular, I would recommend installing LyX (and TeX distribution such as TeXLive or MikTex, depending on your platform) and getting used to the program as a user. If you're not familiar with LyX I would suggest going though the Tutorial (available from the Help Menu) and taking a look at the User's guide (from the same menu). As for LaTex, this project requires at least a basic undestanding of what LaTex is, how it interacts with LyX on the one hand and with the Tex engine(s) on the other hand. If you've never used LaTeX before, I would recommend looking at "The not so Short Guide to LaTeX" which is available in every Tex distribution (search for lshort.pdf on your hard drive after you have installed TeX, or type "texdoc lshort" in a terminal if you are on linux). Once you have a general understanding of how LyX works and interacts with LaTeX, I would recommend looking at the bug tracker [2] as a way to get familiar with the code base. In particular, search for bugs marked "easyfix" and see if you can contribute a patch. And do not hesitate to ask questions on the Lyx-devel list! Cheers, Stefano [1] https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg182374.html [2] http://www.lyx.org/trac/wiki/BugTrackerHome On Fri, Feb 28, 2014 at 11:00 AM, Jicksy John wrote: > Hi :) > > I got interested in the Round Trip Conversion project (between LyX and > .docx) formats. > > Would like to know as to how I am supposed to make my earlier contribution. > > Thank you :) > > > -- > Jicksy John > Student > College of Engineering,Chengannur -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
On Fri, Feb 28, 2014 at 9:56 AM, Jürgen Spitzmüller wrote: > Richard Heck wrote: >> Here, I think it's especially helpful to distinguish "round trip" >> conversion, which would be used during collaboration, from final export >> for publication. I take it that in the former case we just need to make >> sure not to lose bibliographic information. Only in the latter case do >> we need to be able to use or mimic biblatex, or whatever, to get the >> bibliographic information into some final form. > > Yes, maybe. But isn't the real and more serious problem, at least in the > humanities, that you are forced to submit papers and chapters in Word format, > notwithstanding if this is collaboration work or an individual's work? > > The possibility to export and re-import strikes me rather secondary compared > to that. But this is of course again just my own experience. > I agree with Jürgen here. Moreover, after having spent a few hours looking at the details of mmd and pandoc formats yesterday night, I've become very skeptical about my previous suggestion to use conversion to either as an intermediate step that would allow both export to Word and round-trip conversions. So it's back to Richard's suggestions of keeping the two projects (export to word vs. roundtrip) separate. The issues I see, however are: - htlatex is in a state of suspended animation. I am not clear for how long if will be maintained, if at all. On the other hand, replicating htlatex's approach (compile with (xe)latex to a special dvi format than parse the dvi output) seems a massive undertaking. - for the roundtrip conversion: is it better to settle on an intermediate format (XML|pandoc|etc) or attempting a direct (and limited) translation? >> This sort of thing has been frequently requested just for XHTML: Parse >> the bbl file and use that to construct the bibliography. So perhaps the >> problem should be solved there first. > > I suppose things get significantly trickier if biblatex comes into play. > Parsing bbl files does not suffice there. > Agreed. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
On Thu, Feb 27, 2014 at 2:36 PM, Richard Heck wrote: > On 02/27/2014 01:29 PM, stefano franchi wrote: >> >> >> >> >> >> I'd like to hear other people's opinions on this. Here is what I think: >> >> - Bibliography support with suitable styles is a must. This feature is as >> crucial to someone working in the Humanities, as math support is for someone >> working in the sciences. With the difference that scientists can often avoid >> conversion to Word, while Humanists just can't. > > > Perhaps it would help to distinguish two projects: (i) Round-trip, for > collaboration; (ii) Export, for sending to a publisher, or whatever. If we > don't want to lose data, then we presumably have to save bibliographic info > as metadata we can reread on import. But if we're only exporting, then we > can either use ODT's bibliography support, e.g., or do the kind of thing we > do with XHTML. > Good point. So here is an idea that may combine the two projects while keeping them separate, and perhaps alleviate, somehow, Rob's (justified) concerns about depending on too many external tools: How about we choose the markdown format used by pandoc (or the similar but slightly different MMD-4) as the intermediate target of both the Lyx to Word and Word to Lyx converters? That way we could start working on a lyx2mmd(-4) module that could be leveraged by pandoc for the final output to word/odt and by a mmd2word/odt module that we could subsequently write. Same for the reverse translation. This approach adds some (perhaps significant) overhead of course. For once, the complete solution would involve modules for lyx2mmd, mmd2lyx, and word2mmd. But it would also give us a fixed target, pretty much in the same sense in which a XML could. Besides, mmd stores math in native latex format. As far as I can tell, MMD supports metadata, so Lyx-only information could be transported across conversions. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
On Thu, Feb 27, 2014 at 12:57 PM, Rob Oakes wrote: > As I've followed the pandoc conversation, I've been concerned about the > introduction of another dependency. If the import/export tools can be > kept to LyX and some processing script, that seems easier to maintain > than a complex chain of tools and external dependencies which we don't > control. In pandoc's case, the issue is further complicated by the fact that it uses Haskell and the additional modules would have to be written in that language, as far as I can tell. So, how many of you guys know it? Do we have a non-empty set? S. -- __________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
On Thu, Feb 27, 2014 at 2:53 PM, stefano franchi wrote: > On Thu, Feb 27, 2014 at 2:50 PM, Richard Heck wrote: >> On 02/27/2014 03:47 PM, stefano franchi wrote: >>> >>> On Thu, Feb 27, 2014 at 2:36 PM, Richard Heck wrote: >>>> >>>> On 02/27/2014 01:29 PM, stefano franchi wrote: >>>>> >>>>> I'd like to hear other people's opinions on this. Here is what I think: >>>>> >>>>> - Bibliography support with suitable styles is a must. This feature is >>>>> as >>>>> crucial to someone working in the Humanities, as math support is for >>>>> someone >>>>> working in the sciences. With the difference that scientists can often >>>>> avoid >>>>> conversion to Word, while Humanists just can't. >>>> >>>> >>>> Perhaps it would help to distinguish two projects: (i) Round-trip, for >>>> collaboration; (ii) Export, for sending to a publisher, or whatever. If >>>> we >>>> don't want to lose data, then we presumably have to save bibliographic >>>> info >>>> as metadata we can reread on import. But if we're only exporting, then we >>>> can either use ODT's bibliography support, e.g., or do the kind of thing >>>> we >>>> do with XHTML. >>> >>> >>> Richard, >>> >>> how does the XHTML export deal with bibliographic references >>> currently? Am I correct that it does not support bst styles at all? At >>> least I could see no differences with a simple document using >>> bibtex+natbib and switching between plainnat and humannat. >> >> >> No, it doesn't pay attention to the BibTeX style at the moment. However, in >> 2.1.x, the different citation styles are handled through modules, and so it >> would in principle be possible to write different modules for different >> BibTeX styles. Alternatively, one could run BibTeX and parse the resulting >> bbl file. The latter might be easier, but assumes LaTeX is installed. >> > > > Ok, thanks. So I assume the latter option---parsing the bbl > file---would work with other engines as well (i.e. biblatex+biber). This is actually wrong, forget I mentioned it. Of course, biblatex is needed again for the final output after the bbl files has been produced. S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats
On Thu, Feb 27, 2014 at 2:50 PM, Richard Heck wrote: > On 02/27/2014 03:47 PM, stefano franchi wrote: >> >> On Thu, Feb 27, 2014 at 2:36 PM, Richard Heck wrote: >>> >>> On 02/27/2014 01:29 PM, stefano franchi wrote: >>>> >>>> I'd like to hear other people's opinions on this. Here is what I think: >>>> >>>> - Bibliography support with suitable styles is a must. This feature is >>>> as >>>> crucial to someone working in the Humanities, as math support is for >>>> someone >>>> working in the sciences. With the difference that scientists can often >>>> avoid >>>> conversion to Word, while Humanists just can't. >>> >>> >>> Perhaps it would help to distinguish two projects: (i) Round-trip, for >>> collaboration; (ii) Export, for sending to a publisher, or whatever. If >>> we >>> don't want to lose data, then we presumably have to save bibliographic >>> info >>> as metadata we can reread on import. But if we're only exporting, then we >>> can either use ODT's bibliography support, e.g., or do the kind of thing >>> we >>> do with XHTML. >> >> >> Richard, >> >> how does the XHTML export deal with bibliographic references >> currently? Am I correct that it does not support bst styles at all? At >> least I could see no differences with a simple document using >> bibtex+natbib and switching between plainnat and humannat. > > > No, it doesn't pay attention to the BibTeX style at the moment. However, in > 2.1.x, the different citation styles are handled through modules, and so it > would in principle be possible to write different modules for different > BibTeX styles. Alternatively, one could run BibTeX and parse the resulting > bbl file. The latter might be easier, but assumes LaTeX is installed. > Ok, thanks. So I assume the latter option---parsing the bbl file---would work with other engines as well (i.e. biblatex+biber). BTW, I guess this project assumes we start from Lyx 2.1? Am I right? S. -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
