Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On Feb 6, 2014, at 10:35 AM, stefano franchi wrote: > The first project in our wiki page for GSOC 2014: > > http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014 > > is, at the same time, the most ambitious and the least well-defined (possibly > because the former implies the latter). > > It is not clear to me if this a coding project or if it defines the outline > of a preliminary non-coding feasibility study that would, at most, produce a > document describing the minimal-lyx and minimal-docx feature sets (plus, > possibly, a minimal-lyx-layout and a minimal-doc-template). > > Any thought on how to make it more focused? > > Perhaps we could define the goals as: > > 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX features) > 2. Write a corresponding lyx-layout > 3. Define a minimal-doc feature set (Word/ODF features corresponding to (1) > 4, Write a Word/OO template (the set of styles corresponding to 2) > 5. Provide an automated path from 1 to 4 and back using glue-code and > existing internal and external tools (e.g.: LyX export functions to > XHTML/EPub, eLyxer, pandoc, writer2latex, etc). > > I am not sure points 1-5 above capture the existing description, partly > because I am not sure about what is meant by "develop a framework". Perhaps > my summary caputeres the subgoal only? > > Stefano One can hope (right?) that since a commonality between LyX and docx is math that this would be included on the feature set(s). On OS X, the new versions of Word have a built-in math typesetting capability (and thus no longer depends on MathType). Presumably this is allowed by the docx format and presumably this is also an aspect of Windows Word. Autonumbering would also be hoped for. Jerry > > > -- > __ > 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: On GSOC 2014 application--again
On Thu, Feb 6, 2014 at 8:00 PM, Cyrille Artho wrote: > Let me just wrap this up then... > I think the current approaches to R security are not quite ready yet, and a > project related to that would be a project about R, not LyX. OK. > However, simply issuing a warning when R scripts are present is IMHO too > trivial for a GSoC project. And I think this idea would be rejected because it is too intrusive to the user. > We could include small things like that if we are thinking about > participating in Google Code-In instead. (I have never participated in that, > but GCI would be useful if we have many small tasks, including things not > related to code such as icon design, documentation, translation, etc.). Good to know. Scott
Re: On GSOC 2014 application--again
Let me just wrap this up then... I think the current approaches to R security are not quite ready yet, and a project related to that would be a project about R, not LyX. However, simply issuing a warning when R scripts are present is IMHO too trivial for a GSoC project. We could include small things like that if we are thinking about participating in Google Code-In instead. (I have never participated in that, but GCI would be useful if we have many small tasks, including things not related to code such as icon design, documentation, translation, etc.). Scott Kostyshak wrote: On Thu, Feb 6, 2014 at 7:07 PM, Cyrille Artho wrote: Feasible idea #3 I still think something should be done about the fact that a user can open a LyX file that someone posted asking for help, compile, and have all of his/her $HOME files uploaded/deleted. This is because of the knitr/Sweave module (and an inset can be easily closed and hidden). The user should be notified whenever a file has a "dangerous" module for the first time. Richard had a good idea for solving the security issue but not being intrusive (= only warning a user once per file even if that file is subsequently changed). I believe it is complicated enough for a GSoC but I don't think other LyX devels are as interested in this being implemented as I am. I have only used R a few times, and was not aware that it runs without restrictions. That's pretty scary... So IMHO this should be fixed in R and not in LyX, if possible. I haven't seen a completed and easy way to implement this (see more below). Unfortunately, I was not able to find a way to search the mailing list archive of the R-devel mailing list, and I'm not familiar with the community. However, I've found two efforts to make R more secure: * RAppArmor: Use Linux' AppArmor to restrict R: http://arxiv.org/pdf/1303.4808 * R in the JVM: Take advantage of the JVM's sandboxing: http://code.google.com/p/renjin/ The former link is a technical report that has just been published (Nov. 2013), so the code is likely not yet ready for a release. The latter link is also work in progress, but it seems to be coming along well; a first release may come out soon. I think it's the better choice for LyX as it is not platform dependent. Here are more relevant links: http://r.789695.n4.nabble.com/Scanning-a-R-script-for-potentially-insidious-commands-td4653507.html https://github.com/Rapporter/sandboxR https://github.com/jeroenooms/RAppArmor Based on this, we could give the user three choices when finding a file that uses R (via knitr or sweave): * Trust the R code by running the script natively. Warn the user that the code could potentially destroy data. * Run restricted R (once Renjin is released). Requires a JVM installation, and may not be compatible with all R modules. * I'm scared! Do not open the file. If you want, we should continue the conversation in a different thread. I do not want to hijack this one. Scott -- Regards, Cyrille Artho - http://artho.com/ The more numerous the laws, the more corrupt the government. -- Tacitus
Re: On GSOC 2014 application--again
On Thu, Feb 6, 2014 at 7:07 PM, Cyrille Artho wrote: >> >> Feasible idea #3 >> >> I still think something should be done about the fact that a user can >> open a LyX file that someone posted asking for help, compile, and have >> all of his/her $HOME files uploaded/deleted. This is because of the >> knitr/Sweave module (and an inset can be easily closed and hidden). >> The user should be notified whenever a file has a "dangerous" module >> for the first time. Richard had a good idea for solving the security >> issue but not being intrusive (= only warning a user once per file >> even if that file is subsequently changed). I believe it is >> complicated enough for a GSoC but I don't think other LyX devels are >> as interested in this being implemented as I am. > > I have only used R a few times, and was not aware that it runs without > restrictions. That's pretty scary... > > So IMHO this should be fixed in R and not in LyX, if possible. I haven't seen a completed and easy way to implement this (see more below). > Unfortunately, I was not able to find a way to search the mailing list > archive of the R-devel mailing list, and I'm not familiar with the > community. However, I've found two efforts to make R more secure: > > * RAppArmor: Use Linux' AppArmor to restrict R: > > http://arxiv.org/pdf/1303.4808 > > * R in the JVM: Take advantage of the JVM's sandboxing: > > http://code.google.com/p/renjin/ > > The former link is a technical report that has just been published (Nov. > 2013), so the code is likely not yet ready for a release. > > The latter link is also work in progress, but it seems to be coming along > well; a first release may come out soon. I think it's the better choice for > LyX as it is not platform dependent. Here are more relevant links: http://r.789695.n4.nabble.com/Scanning-a-R-script-for-potentially-insidious-commands-td4653507.html https://github.com/Rapporter/sandboxR https://github.com/jeroenooms/RAppArmor > > Based on this, we could give the user three choices when finding a file that > uses R (via knitr or sweave): > > * Trust the R code by running the script natively. Warn the user that the > code could potentially destroy data. > > * Run restricted R (once Renjin is released). Requires a JVM installation, > and may not be compatible with all R modules. > > * I'm scared! Do not open the file. If you want, we should continue the conversation in a different thread. I do not want to hijack this one. Scott
Re: On GSOC 2014 application--again
> > Feasible idea #3 > > I still think something should be done about the fact that a user can > open a LyX file that someone posted asking for help, compile, and have > all of his/her $HOME files uploaded/deleted. This is because of the > knitr/Sweave module (and an inset can be easily closed and hidden). > The user should be notified whenever a file has a "dangerous" module > for the first time. Richard had a good idea for solving the security > issue but not being intrusive (= only warning a user once per file > even if that file is subsequently changed). I believe it is > complicated enough for a GSoC but I don't think other LyX devels are > as interested in this being implemented as I am. I have only used R a few times, and was not aware that it runs without restrictions. That's pretty scary... So IMHO this should be fixed in R and not in LyX, if possible. Unfortunately, I was not able to find a way to search the mailing list archive of the R-devel mailing list, and I'm not familiar with the community. However, I've found two efforts to make R more secure: * RAppArmor: Use Linux' AppArmor to restrict R: http://arxiv.org/pdf/1303.4808 * R in the JVM: Take advantage of the JVM's sandboxing: http://code.google.com/p/renjin/ The former link is a technical report that has just been published (Nov. 2013), so the code is likely not yet ready for a release. The latter link is also work in progress, but it seems to be coming along well; a first release may come out soon. I think it's the better choice for LyX as it is not platform dependent. Based on this, we could give the user three choices when finding a file that uses R (via knitr or sweave): * Trust the R code by running the script natively. Warn the user that the code could potentially destroy data. * Run restricted R (once Renjin is released). Requires a JVM installation, and may not be compatible with all R modules. * I'm scared! Do not open the file. -- Regards, Cyrille Artho - http://artho.com/ Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll invite himself over for dinner. -- Calvin Keegan
Re: "Recursive paint detected" when opening APA6 template (2.1git)
On Sat, Feb 1, 2014 at 4:30 PM, Kornel Benko wrote: > Am Samstag, 1. Februar 2014 um 15:21:40, schrieb Scott Kostyshak > > >> On Sat, Feb 1, 2014 at 7:23 AM, Vincent van Ravesteijn >> wrote: > >> > Scott Kostyshak schreef op 18-1-2014 23:17: > >> > > >> >> When I go to File > New From Templates > APA6.lyx > >> >> I get the following terminal output: > >> >> > >> >> QWidget::repaint: Recursive repaint detected > >> >> QWidget::paintEngine: Should no longer be called > >> >> QPainter::begin: Paint device returned engine == 0, type: 1 > >> >> > >> >> This is on Ubuntu 13.10 with current 2.1git. > >> >> > >> >> Can anyone reproduce? > >> >> > >> >> Scott > >> > > >> > > >> > Some time ago we were using the wrong Qt function (repaint, update, I > >> > forgot) to update which caused a lot of those warnings and errors. > >> > > >> > I've been hunting this before, but I couldn't find the problem. > >> > >> Could you or Kornel (or anyone else) reproduce seeing the message or > >> is it just for me? > > > > I tried again, this time on ubuntu 12.10, but no such message here. Can you try on master with the following: 1. open lyx from the terminal 2. maximize LyX 3. File > New from Template > APA6.lyx I just realized that Step 2 is necessary for me to reproduce. Scott
Re: On GSOC 2014 application--again
On Thu, Feb 6, 2014 at 4:25 PM, stefano franchi wrote: > Dear Lyx devels, > > I have received very few responses to my previous round call of possible > mentors for the upcoming 2014 GSOC. > - Scott (Horizontal scrollbar for tables and math) [1] I never actually helped on this. All the burden was on JMarc. I'm not qualified enough to be a primary mentor on any of the projects. I've been trying to think of a project that I would be qualified for. Below are some ideas. Feasible idea #1 Here is my most feasible idea so far: An integrated grammar checker. Reasons why I call this "feasible": - There is a chance that John McCabe-Dansted would be interested in being co-mentor (although I have not asked him). - There has already been work done on it [2]. - (the main advantage) It could be implemented in a similar way to LyX's spell checker. If LyX can find a grammar checking library (e.g. Language Tool [1]), then the feature is enabled, just like LyX's spell checker looks for spellchecking dictionaries. I believe that there are enough similarities to the spell checker that the student and I could learn from the spell checker code; but that there are enough challenges (e.g. the input would not be just one word) that it would be a significant workload and contribution. Feasible idea #2 - CAS Integration with SAGE or (better) integration with Maxima. We often get complaints that LyX does not have good enough CAS support. I think that this is straight-forward enough that I could mentor better integration. There are not clearly defined goals though. We would need to identify things that are not working and make it clear what needs to be fixed. Feasible idea #3 I still think something should be done about the fact that a user can open a LyX file that someone posted asking for help, compile, and have all of his/her $HOME files uploaded/deleted. This is because of the knitr/Sweave module (and an inset can be easily closed and hidden). The user should be notified whenever a file has a "dangerous" module for the first time. Richard had a good idea for solving the security issue but not being intrusive (= only warning a user once per file even if that file is subsequently changed). I believe it is complicated enough for a GSoC but I don't think other LyX devels are as interested in this being implemented as I am. Thoughts? Scott [1] https://www.languagetool.org/ [2] http://wiki.lyx.org/Tools/LyX-GrammarChecker
Re: On GSOC 2014 application--again
> I would like to ask, in particular, those mentors who had volunteered last > year but whose projects were not chosen if they are still available. That > means: > > - Pavel (LyX support for bilingual (critical) text editions) Neither I have time nor I see any prospective student on mailing list. Chance of students returning back seems to be zero when they suddenly appear because of google money. Pavel
On GSOC 2014 application--again
Dear Lyx devels, I have received very few responses to my previous round call of possible mentors for the upcoming 2014 GSOC. All I know is: Richard: not available Juergen: not available Cyrille: most likely not available Vincent: available, unsure on which project So we have 1 possible mentor so far, which would falls seriously short of what's needed. On the other hand, there is no shortage of projects. In addition to those listed on the new GSOC 2014 wiki page, there are also the well-described projects in last year's page that did not get chosen. I would like to ask, in particular, those mentors who had volunteered last year but whose projects were not chosen if they are still available. That means: - Abdel (layout editor, toolbar customization dialogue) - Pavel (LyX support for bilingual (critical) text editions) - Tommaso (advanced find and replace, Chat client, interactive lyx) - Scott (Horizontal scrollbar for tables and math) [1] Please let me know, as the deadline is approaching fast. Cheers, Stefano [1] Some work was done on this project, though. I am not clear whether it's ready to be integrated into 2.1 (or 2.2) or whether a second round would be necessary. -- __ 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
[patch] Fix bug 8874 Chunk insets behave differently form ERT insets when applying formatting
This is one of three bugs scheduled for 2.1.0: If you apply font changes,
e.g. small size to a paragraph including a chunk inset, the result will not
be compilable anymore (only after saving and reloading the document).
Jean-Marc did the detective work and found out the reason: resetFontEdit()
returns the wrong value for chunk insets. The attached patch fixes that by
setting the correct value in the layout file, and making the defaults of
resetFontEdit() and inheritFont() compatible. See
http://www.lyx.org/trac/ticket/8874 if you want to understand all details.
I tested this patch extensively, and it works fine now (it is the third
version), but since it involves a layout file format change I'd rather ask:
Is it OK to go in? Of course I would convert all other layout files at the
same time.
Georgdiff --git a/lib/layouts/litinsets.inc b/lib/layouts/litinsets.inc
index 8bcee50..05440cb 100644
--- a/lib/layouts/litinsets.inc
+++ b/lib/layouts/litinsets.inc
@@ -6,7 +6,7 @@
# Note that this file is included in sweave.module,
# knitr.module and noweb.module.
-Format 48
+Format 49
Counter chunk
PrettyFormat "Chunk ##"
@@ -43,4 +43,5 @@ InsetLayout "Flex:Chunk"
LeftDelim <<
RightDelim>>=
EndArgument
+ResetsFont false
End
diff --git a/lib/scripts/layout2layout.py b/lib/scripts/layout2layout.py
index 36e4130..8644017 100644
--- a/lib/scripts/layout2layout.py
+++ b/lib/scripts/layout2layout.py
@@ -162,6 +162,9 @@ import os, re, string, sys
# Incremented to format 48, 31 May 2013 by rgh
# Add InitialValue tag for counters
+# Incremented to format 49, 04 Feb 2014 by gb
+# Change default of "ResetsFont" tag to false
+
# Do not forget to document format change in Customization
# Manual (section "Declaring a new text class").
@@ -169,7 +172,7 @@ import os, re, string, sys
# development/tools/updatelayouts.sh script to update all
# layout files to the new format.
-currentFormat = 48
+currentFormat = 49
def usage(prog_name):
@@ -255,6 +258,7 @@ def convert(lines):
re_Builtin = re.compile(r'^(\s*)LaTeXBuiltin\s+(\w*)', re.IGNORECASE)
re_True = re.compile(r'^\s*(?:true|1)\s*$', re.IGNORECASE)
re_InsetLayout = re.compile(r'^\s*InsetLayout\s+(?:Custom|CharStyle|Element):(\S+)\s*$', re.IGNORECASE)
+re_ResetsFont = re.compile(r'^(\s*)ResetsFont(\s+)(\S+)$', re.IGNORECASE)
# with quotes
re_QInsetLayout = re.compile(r'^\s*InsetLayout\s+"(?:Custom|CharStyle|Element):([^"]+)"\s*$', re.IGNORECASE)
re_InsetLayout_CopyStyle = re.compile(r'^\s*CopyStyle\s+(?:Custom|CharStyle|Element):(\S+)\s*$', re.IGNORECASE)
@@ -330,6 +334,11 @@ def convert(lines):
opts = 0
reqs = 0
inchapter = False
+isflexlayout = False # only used for 48 -> 49
+# Whether a style is inherited (works only for CopyStyle currently,
+# not for true inherited styles, see bug 8920
+inherited = False# only used for 48 -> 49
+resetsfont_found = False # only used for 48 -> 49
while i < len(lines):
# Skip comments and empty lines
@@ -386,6 +395,42 @@ def convert(lines):
i += 1
continue
+if format == 48:
+# The default of ResetsFont in LyX changed from true to false,
+# because it is now used for all InsetLayouts, not only flex ones.
+# Therefore we need to set it to true for all flex insets which do
+# do not already have a ResetsFont.
+match = re_InsetLayout2.match(lines[i])
+if match:
+resetsfont_found = False
+inherited = False
+name = string.lower(match.group(1))
+if name == "flex" or name[:5] == "flex:":
+isflexlayout = True
+else:
+isflexlayout = False
+match = re_ResetsFont.match(lines[i])
+if match:
+resetsfont_found = True
+match = re_End.match(lines[i])
+if match:
+if isflexlayout and not resetsfont_found and not inherited:
+lines.insert(i, "\tResetsFont true")
+i += 1
+match = re_Style.match(lines[i])
+if match:
+isflexlayout = False
+inherited = False
+match = re_Counter.match(lines[i])
+if match:
+isflexlayout = False
+inherited = False
+match = re_CopyStyle.match(lines[i])
+if match:
+inherited = True
+i += 1
+continue
+
if format >= 44 and format <= 47:
# nothing to do.
i += 1
diff --git a/src/TextClass.cpp b/src/TextClass.cpp
index b77f31b..9d4509c 100644
--- a/src/TextClass.cpp
+++ b/src/TextClass.cpp
@@ -61,7 +61,7 @@ namespace lyx {
// development/tools/updatelayouts.sh script, to update the format of
// all of our layou
Re: [LyX/master] Document paste options (bug #8749)
Uwe Stöhr wrote: > thanks for the description of the different paste modes. But as I need to > update the other languages accordingly, please use change tracking. No problem, I'll do that next time. Is that documented somewhere? I vaguely remember that I used to use change tracking for manuals, and then somebody told me it was not wanted. Georg
Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion
On Thu, Feb 6, 2014 at 12:36 PM, Liviu Andronic wrote: > On Thu, Feb 6, 2014 at 6:35 PM, stefano franchi > wrote: > > The first project in our wiki page for GSOC 2014: > > > > http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014 > > > > is, at the same time, the most ambitious and the least well-defined > > (possibly because the former implies the latter). > > > > It is not clear to me if this a coding project or if it defines the > outline > > of a preliminary non-coding feasibility study that would, at most, > produce a > > document describing the minimal-lyx and minimal-docx feature sets (plus, > > possibly, a minimal-lyx-layout and a minimal-doc-template). > > > > Any thought on how to make it more focused? > > > Rob has already done some work on this, with a working first release: > http://blog.oak-tree.us/index.php/2012/03/08/word2lyx01-2 > > Maybe that could be a starting point, and perhaps he has some pointers > on what can/needs to be done. > > This is great news. I was unaware of Rob's work in this area. I guess it's take care of both points (3) and (4) (and half of (5)) in my list. At list in a preliminary way. Perhaps we could focus on Python skills and on familiarity with LyX/LaTeX and Word formats? If so, I'd be willing to be potential mentor for the project, unless Rob wants to step in. The conversion to Word and the correlated problems when cooperating with non-LyX using colleagues is by far the biggest problem I have with LyX and I would love to see some progress on it. 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 2014 project list: on LyX<-->docx roundtrip conversion
On Thu, Feb 6, 2014 at 6:35 PM, stefano franchi wrote: > The first project in our wiki page for GSOC 2014: > > http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014 > > is, at the same time, the most ambitious and the least well-defined > (possibly because the former implies the latter). > > It is not clear to me if this a coding project or if it defines the outline > of a preliminary non-coding feasibility study that would, at most, produce a > document describing the minimal-lyx and minimal-docx feature sets (plus, > possibly, a minimal-lyx-layout and a minimal-doc-template). > > Any thought on how to make it more focused? > Rob has already done some work on this, with a working first release: http://blog.oak-tree.us/index.php/2012/03/08/word2lyx01-2 Maybe that could be a starting point, and perhaps he has some pointers on what can/needs to be done. Liviu > Perhaps we could define the goals as: > > 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX features) > 2. Write a corresponding lyx-layout > 3. Define a minimal-doc feature set (Word/ODF features corresponding to (1) > 4, Write a Word/OO template (the set of styles corresponding to 2) > 5. Provide an automated path from 1 to 4 and back using glue-code and > existing internal and external tools (e.g.: LyX export functions to > XHTML/EPub, eLyxer, pandoc, writer2latex, etc). > > I am not sure points 1-5 above capture the existing description, partly > because I am not sure about what is meant by "develop a framework". Perhaps > my summary caputeres the subgoal only? > > 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 -- Do you know how to read? http://www.alienetworks.com/srtest.cfm http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
GSOC 2014 project list: on LyX<-->docx roundtrip conversion
The first project in our wiki page for GSOC 2014: http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014 is, at the same time, the most ambitious and the least well-defined (possibly because the former implies the latter). It is not clear to me if this a coding project or if it defines the outline of a preliminary non-coding feasibility study that would, at most, produce a document describing the minimal-lyx and minimal-docx feature sets (plus, possibly, a minimal-lyx-layout and a minimal-doc-template). Any thought on how to make it more focused? Perhaps we could define the goals as: 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX features) 2. Write a corresponding lyx-layout 3. Define a minimal-doc feature set (Word/ODF features corresponding to (1) 4, Write a Word/OO template (the set of styles corresponding to 2) 5. Provide an automated path from 1 to 4 and back using glue-code and existing internal and external tools (e.g.: LyX export functions to XHTML/EPub, eLyxer, pandoc, writer2latex, etc). I am not sure points 1-5 above capture the existing description, partly because I am not sure about what is meant by "develop a framework". Perhaps my summary caputeres the subgoal only? 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: LaTeX3
29/01/2014 23:04, Andrew Parsloe: I don't recall seeing any mention of LaTeX3 on either developers or users lists over the decade I've been following them. I "discovered" LaTeX3 last year and was struck by how much easier it is to code in TeX using the expl3 language of LaTeX3 rather than directly in TeX/LaTeX2e, and also by the potential for LyX development in LaTeX3 packages like xparse (for the treatment of arguments in insets), and xtemplate (underlying a future LyX layout editor perhaps?). Seeing our current workforce, I do not think that we can be leaders on something like that. We'll probably do something once LaTeX3 is commonly used... JMarc
Re: what does "latex == pdflatex" do?
06/02/2014 17:15, Jürgen Spitzmüller: I've added your thoughts here, in case we get an application for GSOC 14 up and running: http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc4 Please revise. Thanks for doing that Juergen. JMarc
Re: what does "latex == pdflatex" do?
Jean-Marc Lasgouttes wrote: > FWIW, I would like to propose for next GSoC (assuming we have a momentum > towards submitting) a overhaul of out converter scheme where formats can > be qualified through flags. For example, there would be only one pdf > format (and one viewer), but the pdflatex converter would produce > pdf:pdlatex format instead of the ugly pdf2. Converters would use the > specialized version if available, or a generic one. > > I am not sure whether this leads to a change to our path searching > algorithm. The idea is that, once you use a converter that has a > qualifier, the whole path inherits this qualifier and thus can use > different converters. > > This idea is very preliminary for now, but we should try to refactor all > our code that handles different latex flavours, which seems pretty > fragile to me. I've added your thoughts here, in case we get an application for GSOC 14 up and running: http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc4 Please revise. Regards, Jürgen
Re: biblatex native support
Richard Heck wrote: > This may be hard and it may be very hard, but it definitely is not > trivial. A lot of the necessary work was done by Julien when he > modularized the citation stuff. That makes it possible to have modules > that declare different citation commands and then to use them in a > document. But the very different ways that natbib and biblatex declare > styles and then the print bibliography itself, the different types of > styles that biblatex has, etc, etc---none of that has been touched yet. > And that will be a fair amount of work. FWIW, I added some notes here: http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc3 Feel free to extend. Regards, Jürgen
Re: HTML Output Improvement for Listings
On Thu, Jan 9, 2014 at 1:40 PM, Leandro Mattioli wrote:
> Greetings,
>
> I have a small improvement suggestion for LyX. Currently, when a Program
> Listing is inserted by the Child Document feature, the HTML output wraps
> the file contents in a tag.
>
> However, some JavaScript libraries (notably highlight.js), expect source
> code to be enclosed with . Since automatic language detection
> is already available to these libraries. To allow for easier integration
> with these libraries, I suggest the following changes:
>
>
>
> File: insets/InsetInclude.cpp
> Method: InsetInclude::xhtml
>
> // In the case of listings, we wrap it in .
>
> if (listing) {
> xs << html::StartTag("pre");
> xs << html::StartTag("code");
> }
>
> (...)
>
> if (listing) {
> xs << html::EndTag("code");
> xs << html::EndTag("pre");
> }
>
>
>
> With this simple change, one can highlight code only by adding to the
> HTML's head section:
>
>
>
> hljs.initHighlightingOnLoad();
>
> Thanks in advance.
>
Richard,
Have you considered this ?
Vincent
Re: GSOC 2014: Preliminary Call for mentors
Vincent van Ravesteijn wrote: > > Go for the 3 box drawing thing! > > > > Jürgen > > Haha. I was serious. FWIW, I have written up something for a start: http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc2 Feel free to adjust. Regards, Jürgen
Re: #8918: unexpected eof in pk file
On Thu, Feb 6, 2014 at 6:03 AM, Benjamin Ott wrote: > This issue could be fixed by reinstalling the OS. > > -- > Dipl.-Biol. Benjamin Ott > Well, don't shoot the messenger. Vincent
