Re: Pipe in FlexInset Names

[Jean-Marc Lasgouttes]

Le 12/12/2012 05:10, Richard Heck a écrit :

And I am sure we can find some way legitimately to provide the same
functionality in 2.1, which may not be insanely far away now.


We still do not know what the real functionality is :)

JMarc

Re: No bibliography environment in DocBook document class

[José Matos]

On 12/11/2012 03:35 PM, Nico Williams wrote:
 OK, thanks :) that's the answer I was hoping for. Not that I have time
 to contribute code here, but just for my edification: where would I
 look in the source code? In particular I'm using the docbook class but
 exporting to LyXHTML. I'm not sure why I'm doing that -- only that
 I've found that to work best for my purposes (namely: that more
 metadata gets preserved in the resulting XHTML). Thanks! 

Search for docbook methods, you will see them near xhtml methods.
Usually this is a good place to start.

As an example every insert has an export method.

Initial the process to export starts in src/Buffer.cpp then goes to
src/output_docbook.cpp and from there is delegated to the different
elements.

This is the short version. :-)

After this short walk trough if you still have doubts then the next step
is to ask here. :-)

-- 
José Matos

Re: APA6 class with LyX?

[John Kane]

 From: stefano franchi stefano.fran...@gmail.com
To: Ray Rashif schivmeis...@gmail.com 
Cc: Jacob Bishop bishop.ja...@gmail.com; obregonma...@gmail.com; 
lyx-users@lists.lyx.org lyx-users@lists.lyx.org 
Sent: Monday, December 10, 2012 2:01:39 PM
Subject: Re: APA6 class with LyX?
 






On Mon, Dec 10, 2012 at 11:59 AM, Ray Rashif schivmeis...@gmail.com wrote:

On 11 December 2012 01:21, Jacob Bishop bishop.ja...@gmail.com wrote:
 have found very few people in the social sciences who are even aware of
 LaTeX. Not closed minded, just unaware. They use MS Word and Endnote because
 they don't know that there are good/better (free) alternatives.

And this stems from the fact that social science has negligible need
for (typesetting) equations, because that's what really sets LaTeX
apart. With MS Word you can configure references, cite them and
arrange your document based on styles. For qualitative/descriptive
papers, that is enough. As such, few people find any need to go out of
their way to look for something better.



rant
Not true. LyX/Latex's benefits are not limited to typesetting equations 
(although it does a much better job that its competition in that area). A 
Latex-typeset document looks better in many other respects---from 
paragraph-division and typesetting (in spite of recent improvements in Word's 
algorithms), to consistent application of style, down to small but crucial 
things such as determining font sizes/leading[1]. 

The reason why Social sciences/Humanities are happy with Word/Endnote is 
(historically speaking) different: authors used to submit  Word files (or, 
earlier, Wordstar) and the publisher would import and typeset with real 
typesetting software. Such programs (and still are) were usually very bad at 
typesetting complex mathematical formulas unless each single formula was 
tweaked by hand, a very painful and expensive proposition. That was prompted D 
Knuth to invent TeX---the poor quality of professional typesetting software for 
math, not the similar but irrelevant problem in word processing program. The 
lack of equations in the Humanities/Social Sciences made the traditional 
process working smooth and insured that the typographical quality of 
publications in the fields was high, or at least acceptable. Authors used 
primitive (typographically speaking) software, publishers used real typesetters 
and everyone was happy.

Except...that desktop publishing happened and publishers started to cut down on 
costs by using word as a typesetting program. Even worse, when they started 
asking for pdf,  camera-ready  they would provide typographical specs as series 
of Word instructions, since they do not know any better (all the typesetters 
having long gone). The result is that the vast majority of Humanities/Social 
Sciences journal and and increasing number of Humanities *books*  are now 
typographically ugly and often barely readable

The same radical cost-cutting  measures took place  in the Natural 
sciences/Engineering, of course. But since *they* were already using Latex/TeX, 
the quality of their journal and books was only minimally affected (although it 
was: it takes a truly capable typesetter to achieve high results in 
Latex--relying on standard classes is only the starting point. And most authors 
not named Knuth are not great typesetters).

That's why we in the Humanities are stuck with Word as a publishing 
tool---because it used to work well as a drafting tool when the industry worked 
differently, not because we do not use equations.

/rant

Now, now, remain calm.  Of course, just to reinforce your point have a look at 
http://www.apa.org/pubs/authors/instructions.aspx  on  page 2  which points out 
the sorry state at least in the APA journals.  The assumption is Word though it 
is not required otherwise unless some journals do specifically request it.

Display Equations

We strongly encourage you to use MathType (third-party software) or Equation 
Editor 3.0 (built into pre-2007 versions of Word) to construct your equations, 
rather than the equation support that is built into Word 2007 and Word 2010. 
Equations composed with the built-in Word 2007/Word 2010 equation support are 
converted to low resolution graphics when they enter the production process and 
must be rekeyed by the typesetter, which may introduce errors.



 


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies            Ph:   +1 (979) 845-2125
Texas AM University                          Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

Gregory Jefferis wrote:
  In such world even knowing what merging or branching means qualifies
 I think the idea of merging is pretty obvious ? 

If you mean git merge then I'm happy to tell you that some people I need to 
work with even don't
know what is command line in which you can write the command or decrypt 
whatever comes from git
in case of conflict :)

One solution would be to detect merge conflicts and call our diff algorithm for 
the different versions.
This would be beautiful but an order of magnitude harder to implement (surely 
not me:)

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

I know what I need, but the question was about your workflow.
In particular, does it make sense in your case to automatically push after 
commit?

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

Maybe more powerful, but simpler? I have hard time to understand how resolving 
merge conflicts is _simpler_ than automatical locking part of the document you 
work on.
But Ok, we don't agree here, let is sleep.

 what would be more important for my workflow is the ability to do merges by a 
 functional diff in lyx.

This is the key point and I recommend that you add some comment or CC-yourself 
in bug #6889
to indicate that this bug hunts more people and add it more importance...

Cheers,
Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 12 Dec 2012, at 13:49, Pavel Sanda wrote:

 I think the idea of merging is pretty obvious ? 
 
 If you mean git merge then I'm happy to tell you that some people I need to 
 work with even don't
 know what is command line in which you can write the command or decrypt 
 whatever comes from git
 in case of conflict :)
 
 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.

that is exactly what I had in mind

 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) pull (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)
 
 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.
 
 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

 But Ok, we don't agree here, let is sleep.

OK!

 what would be more important for my workflow is the ability to do merges by 
 a functional diff in lyx.
 
 This is the key point and I recommend that you add some comment or 
 CC-yourself in bug #6889
 to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

http://www.lyx.org/trac/ticket/6889

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda sa...@lyx.org wrote:
 Gregory Jefferis wrote:

 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.
 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

That's what I want.  I think it's quite doable if we have a consistent
XML representation of LyX that can be converted in both directions.
That's because there are nice XML diff algorithms.  LyX already
supports conversions to XHTML that are reasonably faithful (more on
that some other time), but there's no XML-LyX converter.

I can't contribute much C++ code to LyX, but I could contribute XSLs
to do XML-.lyx conversion, if you point me at documentation on how
the .lyx format and the LyXHTML and XHTML export formats (specifically
what conventions are used to represent LyX elements in XHTML).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

I don't want LyX to be in the business of being a git GUI, but if it
were going to be so we'd need either to always do git commit -a
(ouch), or git add the files LyX knows were touched (risky) then
commit those, or have a git add UI then git commit.  That's either
unsatisfying or a lot of work, so I'd rather LyX stay out of the git
UI business.

What I want is that if git (or whatever) has merged a .lyx file *with*
conflicts, then LyX should be able to display those such that a user
could fix them by normal editing operations in LyX.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.
 But Ok, we don't agree here, let is sleep.

Locking is simpler until you realize that it causes serious problems
(already discussed).

I don't want to stop you from locking.  I want the option to merge.

Nico
--

Re: APA6 class with LyX?

[Denis J Navas]

John Kane jrkrid...@yahoo.ca escribió en el mensaje de 
noticias:1355320240.2678.yahoomail...@web162406.mail.bf1.yahoo.com...





From: Uwe Stöhr uwesto...@web.de
To: obregonma...@gmail.com 
Cc: lyx-users@lists.lyx.org 
Sent: Monday, December 10, 2012 7:34:36 PM
Subject: Re: APA6 class with LyX?


Am 11.12.2012 01:14, schrieb obregonma...@gmail.com:

 Each APA-type journal has its own list of document types that it accepts; 
 these journals are only guided by the APA _style_ conventions. All journals 
 in psychology etc. that I have come across accept tex manuscripts, as long as 
 the tex file contains everything the authors use (i.e., macros) and do not 
 rely on any special latex compiling instructions.

Thanks for the clarification. So a layout for APA  6 is indeed useful.  
However, I won't have time to write it and hope that anybody else can 
volunteer. if you like, I can review the layout.

thanks and regards
Uwe

Hi Uwe,

That would be great. I am not sure that I have enough knowledge to help but I 
certainly would consider it.

One of the reasons I first asked about this was not so much about direct 
submission for publication though that is very important--the APA 5th Manual 
says that over a 1000 non-APA journals use the Manual but because every 
psychology student in North America and from what I see, in at least most of 
the English-speaking psychological world uses it in preparing papers plus 
French speaking students in Québec. There are suggestions here and there that 
the style is used in several (many?) other languages .  This also seems to 
extend to Education, Nursing  and a host of other social science disciplines 
that I am not familiar with.

Essentially a paper for these students must conform pretty much exactly to the 
equivalent of \documentclass[man,12pt]{apa6}.  I don't know know if there is a 
hard-science or math equivalent: Perhaps all undergraduate math student 
assignments need to match AMA formatting guidelines?   

At a rough guess, students in my city with a community college, one small and 
one medium sized unviersty probably submit 5,000 APA formatted papers each 
year. Also, as others have mentioned, with a bit of minor tweaking APA sets the 
style for theses or disertations in a broad range of disciplines.  Come to 
think of it, other disciplinces with less stringent stylistic demands may well 
be very happy with \documentclass[doc,12pt]{apa6}.

So my thought was let's catch them while they are young. From my own experience 
and talking to some current students using APA can be a real hassle and a 
decent apa6 option in LyX would likely be a real crowd pleaser, especially once 
they learned about bibtex.  





Universities here in Nicaragua, use APA style for thesis.

Denis J Navas

Re: Pipe in FlexInset Names

[Jean-Marc Lasgouttes]

Le 12/12/2012 05:10, Richard Heck a écrit :

And I am sure we can find some way legitimately to provide the same
functionality in 2.1, which may not be insanely far away now.


We still do not know what the real functionality is :)

JMarc

Re: No bibliography environment in DocBook document class

[José Matos]

On 12/11/2012 03:35 PM, Nico Williams wrote:
 OK, thanks :) that's the answer I was hoping for. Not that I have time
 to contribute code here, but just for my edification: where would I
 look in the source code? In particular I'm using the docbook class but
 exporting to LyXHTML. I'm not sure why I'm doing that -- only that
 I've found that to work best for my purposes (namely: that more
 metadata gets preserved in the resulting XHTML). Thanks! 

Search for docbook methods, you will see them near xhtml methods.
Usually this is a good place to start.

As an example every insert has an export method.

Initial the process to export starts in src/Buffer.cpp then goes to
src/output_docbook.cpp and from there is delegated to the different
elements.

This is the short version. :-)

After this short walk trough if you still have doubts then the next step
is to ask here. :-)

-- 
José Matos

Re: APA6 class with LyX?

[John Kane]

 From: stefano franchi stefano.fran...@gmail.com
To: Ray Rashif schivmeis...@gmail.com 
Cc: Jacob Bishop bishop.ja...@gmail.com; obregonma...@gmail.com; 
lyx-users@lists.lyx.org lyx-users@lists.lyx.org 
Sent: Monday, December 10, 2012 2:01:39 PM
Subject: Re: APA6 class with LyX?
 






On Mon, Dec 10, 2012 at 11:59 AM, Ray Rashif schivmeis...@gmail.com wrote:

On 11 December 2012 01:21, Jacob Bishop bishop.ja...@gmail.com wrote:
 have found very few people in the social sciences who are even aware of
 LaTeX. Not closed minded, just unaware. They use MS Word and Endnote because
 they don't know that there are good/better (free) alternatives.

And this stems from the fact that social science has negligible need
for (typesetting) equations, because that's what really sets LaTeX
apart. With MS Word you can configure references, cite them and
arrange your document based on styles. For qualitative/descriptive
papers, that is enough. As such, few people find any need to go out of
their way to look for something better.



rant
Not true. LyX/Latex's benefits are not limited to typesetting equations 
(although it does a much better job that its competition in that area). A 
Latex-typeset document looks better in many other respects---from 
paragraph-division and typesetting (in spite of recent improvements in Word's 
algorithms), to consistent application of style, down to small but crucial 
things such as determining font sizes/leading[1]. 

The reason why Social sciences/Humanities are happy with Word/Endnote is 
(historically speaking) different: authors used to submit  Word files (or, 
earlier, Wordstar) and the publisher would import and typeset with real 
typesetting software. Such programs (and still are) were usually very bad at 
typesetting complex mathematical formulas unless each single formula was 
tweaked by hand, a very painful and expensive proposition. That was prompted D 
Knuth to invent TeX---the poor quality of professional typesetting software for 
math, not the similar but irrelevant problem in word processing program. The 
lack of equations in the Humanities/Social Sciences made the traditional 
process working smooth and insured that the typographical quality of 
publications in the fields was high, or at least acceptable. Authors used 
primitive (typographically speaking) software, publishers used real typesetters 
and everyone was happy.

Except...that desktop publishing happened and publishers started to cut down on 
costs by using word as a typesetting program. Even worse, when they started 
asking for pdf,  camera-ready  they would provide typographical specs as series 
of Word instructions, since they do not know any better (all the typesetters 
having long gone). The result is that the vast majority of Humanities/Social 
Sciences journal and and increasing number of Humanities *books*  are now 
typographically ugly and often barely readable

The same radical cost-cutting  measures took place  in the Natural 
sciences/Engineering, of course. But since *they* were already using Latex/TeX, 
the quality of their journal and books was only minimally affected (although it 
was: it takes a truly capable typesetter to achieve high results in 
Latex--relying on standard classes is only the starting point. And most authors 
not named Knuth are not great typesetters).

That's why we in the Humanities are stuck with Word as a publishing 
tool---because it used to work well as a drafting tool when the industry worked 
differently, not because we do not use equations.

/rant

Now, now, remain calm.  Of course, just to reinforce your point have a look at 
http://www.apa.org/pubs/authors/instructions.aspx  on  page 2  which points out 
the sorry state at least in the APA journals.  The assumption is Word though it 
is not required otherwise unless some journals do specifically request it.

Display Equations

We strongly encourage you to use MathType (third-party software) or Equation 
Editor 3.0 (built into pre-2007 versions of Word) to construct your equations, 
rather than the equation support that is built into Word 2007 and Word 2010. 
Equations composed with the built-in Word 2007/Word 2010 equation support are 
converted to low resolution graphics when they enter the production process and 
must be rekeyed by the typesetter, which may introduce errors.



 


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies            Ph:   +1 (979) 845-2125
Texas AM University                          Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

Gregory Jefferis wrote:
  In such world even knowing what merging or branching means qualifies
 I think the idea of merging is pretty obvious ? 

If you mean git merge then I'm happy to tell you that some people I need to 
work with even don't
know what is command line in which you can write the command or decrypt 
whatever comes from git
in case of conflict :)

One solution would be to detect merge conflicts and call our diff algorithm for 
the different versions.
This would be beautiful but an order of magnitude harder to implement (surely 
not me:)

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

I know what I need, but the question was about your workflow.
In particular, does it make sense in your case to automatically push after 
commit?

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

Maybe more powerful, but simpler? I have hard time to understand how resolving 
merge conflicts is _simpler_ than automatical locking part of the document you 
work on.
But Ok, we don't agree here, let is sleep.

 what would be more important for my workflow is the ability to do merges by a 
 functional diff in lyx.

This is the key point and I recommend that you add some comment or CC-yourself 
in bug #6889
to indicate that this bug hunts more people and add it more importance...

Cheers,
Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 12 Dec 2012, at 13:49, Pavel Sanda wrote:

 I think the idea of merging is pretty obvious ? 
 
 If you mean git merge then I'm happy to tell you that some people I need to 
 work with even don't
 know what is command line in which you can write the command or decrypt 
 whatever comes from git
 in case of conflict :)
 
 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.

that is exactly what I had in mind

 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) pull (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)
 
 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.
 
 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

 But Ok, we don't agree here, let is sleep.

OK!

 what would be more important for my workflow is the ability to do merges by 
 a functional diff in lyx.
 
 This is the key point and I recommend that you add some comment or 
 CC-yourself in bug #6889
 to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

http://www.lyx.org/trac/ticket/6889

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda sa...@lyx.org wrote:
 Gregory Jefferis wrote:

 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.
 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

That's what I want.  I think it's quite doable if we have a consistent
XML representation of LyX that can be converted in both directions.
That's because there are nice XML diff algorithms.  LyX already
supports conversions to XHTML that are reasonably faithful (more on
that some other time), but there's no XML-LyX converter.

I can't contribute much C++ code to LyX, but I could contribute XSLs
to do XML-.lyx conversion, if you point me at documentation on how
the .lyx format and the LyXHTML and XHTML export formats (specifically
what conventions are used to represent LyX elements in XHTML).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

I don't want LyX to be in the business of being a git GUI, but if it
were going to be so we'd need either to always do git commit -a
(ouch), or git add the files LyX knows were touched (risky) then
commit those, or have a git add UI then git commit.  That's either
unsatisfying or a lot of work, so I'd rather LyX stay out of the git
UI business.

What I want is that if git (or whatever) has merged a .lyx file *with*
conflicts, then LyX should be able to display those such that a user
could fix them by normal editing operations in LyX.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.
 But Ok, we don't agree here, let is sleep.

Locking is simpler until you realize that it causes serious problems
(already discussed).

I don't want to stop you from locking.  I want the option to merge.

Nico
--

Re: APA6 class with LyX?

[Denis J Navas]

John Kane jrkrid...@yahoo.ca escribió en el mensaje de 
noticias:1355320240.2678.yahoomail...@web162406.mail.bf1.yahoo.com...





From: Uwe Stöhr uwesto...@web.de
To: obregonma...@gmail.com 
Cc: lyx-users@lists.lyx.org 
Sent: Monday, December 10, 2012 7:34:36 PM
Subject: Re: APA6 class with LyX?


Am 11.12.2012 01:14, schrieb obregonma...@gmail.com:

 Each APA-type journal has its own list of document types that it accepts; 
 these journals are only guided by the APA _style_ conventions. All journals 
 in psychology etc. that I have come across accept tex manuscripts, as long as 
 the tex file contains everything the authors use (i.e., macros) and do not 
 rely on any special latex compiling instructions.

Thanks for the clarification. So a layout for APA  6 is indeed useful.  
However, I won't have time to write it and hope that anybody else can 
volunteer. if you like, I can review the layout.

thanks and regards
Uwe

Hi Uwe,

That would be great. I am not sure that I have enough knowledge to help but I 
certainly would consider it.

One of the reasons I first asked about this was not so much about direct 
submission for publication though that is very important--the APA 5th Manual 
says that over a 1000 non-APA journals use the Manual but because every 
psychology student in North America and from what I see, in at least most of 
the English-speaking psychological world uses it in preparing papers plus 
French speaking students in Québec. There are suggestions here and there that 
the style is used in several (many?) other languages .  This also seems to 
extend to Education, Nursing  and a host of other social science disciplines 
that I am not familiar with.

Essentially a paper for these students must conform pretty much exactly to the 
equivalent of \documentclass[man,12pt]{apa6}.  I don't know know if there is a 
hard-science or math equivalent: Perhaps all undergraduate math student 
assignments need to match AMA formatting guidelines?   

At a rough guess, students in my city with a community college, one small and 
one medium sized unviersty probably submit 5,000 APA formatted papers each 
year. Also, as others have mentioned, with a bit of minor tweaking APA sets the 
style for theses or disertations in a broad range of disciplines.  Come to 
think of it, other disciplinces with less stringent stylistic demands may well 
be very happy with \documentclass[doc,12pt]{apa6}.

So my thought was let's catch them while they are young. From my own experience 
and talking to some current students using APA can be a real hassle and a 
decent apa6 option in LyX would likely be a real crowd pleaser, especially once 
they learned about bibtex.  





Universities here in Nicaragua, use APA style for thesis.

Denis J Navas

Re: Pipe in FlexInset Names

[Jean-Marc Lasgouttes]

Le 12/12/2012 05:10, Richard Heck a écrit :

And I am sure we can find some way legitimately to provide the same
functionality in 2.1, which may not be insanely far away now.


We still do not know what the real functionality is :)

JMarc

Re: No bibliography environment in DocBook document class

[José Matos]

On 12/11/2012 03:35 PM, Nico Williams wrote:
> OK, thanks :) that's the answer I was hoping for. Not that I have time
> to contribute code here, but just for my edification: where would I
> look in the source code? In particular I'm using the docbook class but
> exporting to LyXHTML. I'm not sure why I'm doing that -- only that
> I've found that to work best for my purposes (namely: that more
> metadata gets preserved in the resulting XHTML). Thanks! 

Search for docbook methods, you will see them near xhtml methods.
Usually this is a good place to start.

As an example every insert has an export method.

Initial the process to export starts in src/Buffer.cpp then goes to
src/output_docbook.cpp and from there is delegated to the different
elements.

This is the short version. :-)

After this short walk trough if you still have doubts then the next step
is to ask here. :-)

-- 
José Matos

Re: APA6 class with LyX?

[John Kane]

 From: stefano franchi 
To: Ray Rashif  
Cc: Jacob Bishop ; obregonma...@gmail.com; 
"lyx-users@lists.lyx.org"  
Sent: Monday, December 10, 2012 2:01:39 PM
Subject: Re: APA6 class with LyX?
 






On Mon, Dec 10, 2012 at 11:59 AM, Ray Rashif  wrote:

On 11 December 2012 01:21, Jacob Bishop  wrote:
>> have found very few people in the social sciences who are even aware of
>> LaTeX. Not closed minded, just unaware. They use MS Word and Endnote because
>> they don't know that there are good/better (free) alternatives.
>
>And this stems from the fact that social science has negligible need
>for (typesetting) equations, because that's what really sets LaTeX
>apart. With MS Word you can configure references, cite them and
>arrange your document based on styles. For qualitative/descriptive
>papers, that is enough. As such, few people find any need to go out of
>their way to look for something better.
>
>


Not true. LyX/Latex's benefits are not limited to typesetting equations 
(although it does a much better job that its competition in that area). A 
Latex-typeset document looks better in many other respects---from 
paragraph-division and typesetting (in spite of recent improvements in Word's 
algorithms), to consistent application of style, down to small but crucial 
things such as determining font sizes/leading[1]. 

The reason why Social sciences/Humanities are happy with Word/Endnote is 
(historically speaking) different: authors used to submit  Word files (or, 
earlier, Wordstar) and the publisher would import and typeset with real 
typesetting software. Such programs (and still are) were usually very bad at 
typesetting complex mathematical formulas unless each single formula was 
tweaked by hand, a very painful and expensive proposition. That was prompted D 
Knuth to invent TeX---the poor quality of professional typesetting software for 
math, not the similar but irrelevant problem in word processing program. The 
lack of equations in the Humanities/Social Sciences made the traditional 
process working smooth and insured that the typographical quality of 
publications in the fields was high, or at least acceptable. Authors used 
primitive (typographically speaking) software, publishers used real typesetters 
and everyone was happy.

Except...that desktop publishing happened and publishers started to cut down on 
costs by using word as a typesetting program. Even worse, when they started 
asking for pdf,  camera-ready  they would provide typographical specs as series 
of Word instructions, since they do not know any better (all the typesetters 
having long gone). The result is that the vast majority of Humanities/Social 
Sciences journal and and increasing number of Humanities *books*  are now 
typographically ugly and often barely readable

The same radical cost-cutting  measures took place  in the Natural 
sciences/Engineering, of course. But since *they* were already using Latex/TeX, 
the quality of their journal and books was only minimally affected (although it 
was: it takes a truly capable typesetter to achieve high results in 
Latex--relying on standard classes is only the starting point. And most authors 
not named Knuth are not great typesetters).

That's why we in the Humanities are stuck with Word as a publishing 
tool---because it used to work well as a drafting tool when the industry worked 
differently, not because we do not use equations.



Now, now, remain calm.  Of course, just to reinforce your point have a look at 
http://www.apa.org/pubs/authors/instructions.aspx  on  page 2  which points out 
the sorry state at least in the APA journals.  The assumption is Word though it 
is not required otherwise unless some journals do specifically request it.

Display Equations

We strongly encourage you to use MathType (third-party software) or Equation 
Editor 3.0 (built into pre-2007 versions of Word) to construct your equations, 
rather than the equation support that is built into Word 2007 and Word 2010. 
Equations composed with the built-in Word 2007/Word 2010 equation support are 
converted to low resolution graphics when they enter the production process and 
must be rekeyed by the typesetter, which may introduce errors.



 


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies            Ph:   +1 (979) 845-2125
Texas A University                          Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

Gregory Jefferis wrote:
> > In such world even knowing what "merging" or "branching" means qualifies
> I think the idea of merging is pretty obvious ? 

If you mean "git merge" then I'm happy to tell you that some people I need to 
work with even don't
know what is command line in which you can write the command or decrypt 
whatever comes from git
in case of conflict :)

One solution would be to detect merge conflicts and call our diff algorithm for 
the different versions.
This would be beautiful but an order of magnitude harder to implement (surely 
not me:)

> if you wanted to have bare bones support for git in lyx you would need
> * commit (saving your changes)
> * push (share your work)
> * pull (fetch changes and merge with your work)

I know what I need, but the question was about your workflow.
In particular, does it make sense in your case to automatically push after 
commit?

> After testing out the existing svn implementation I think this is actually 
> simpler to automatically merge with git than to lock files with svn.

Maybe more powerful, but simpler? I have hard time to understand how resolving 
merge conflicts is _simpler_ than automatical locking part of the document you 
work on.
But Ok, we don't agree here, let is sleep.

> what would be more important for my workflow is the ability to do merges by a 
> functional diff in lyx.

This is the key point and I recommend that you add some comment or CC-yourself 
in bug #6889
to indicate that this bug hunts more people and add it more importance...

Cheers,
Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

On 12 Dec 2012, at 13:49, Pavel Sanda wrote:

>> I think the idea of merging is pretty obvious ? 
> 
> If you mean "git merge" then I'm happy to tell you that some people I need to 
> work with even don't
> know what is command line in which you can write the command or decrypt 
> whatever comes from git
> in case of conflict :)
> 
> One solution would be to detect merge conflicts and call our diff algorithm 
> for the different versions.

that is exactly what I had in mind

> This would be beautiful but an order of magnitude harder to implement (surely 
> not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) "pull" (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

>> if you wanted to have bare bones support for git in lyx you would need
>> * commit (saving your changes)
>> * push (share your work)
>> * pull (fetch changes and merge with your work)
> 
> I know what I need, but the question was about your workflow.
> In particular, does it make sense in your case to automatically push after 
> commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

>> After testing out the existing svn implementation I think this is actually 
>> simpler to automatically merge with git than to lock files with svn.
> 
> Maybe more powerful, but simpler? I have hard time to understand how 
> resolving merge conflicts is _simpler_ than automatical locking part of the 
> document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

> But Ok, we don't agree here, let is sleep.

OK!

>> what would be more important for my workflow is the ability to do merges by 
>> a functional diff in lyx.
> 
> This is the key point and I recommend that you add some comment or 
> CC-yourself in bug #6889
> to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

http://www.lyx.org/trac/ticket/6889

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda  wrote:
> Gregory Jefferis wrote:

> One solution would be to detect merge conflicts and call our diff algorithm 
> for the different versions.
> This would be beautiful but an order of magnitude harder to implement (surely 
> not me:)

That's what I want.  I think it's quite doable if we have a consistent
XML representation of LyX that can be converted in both directions.
That's because there are nice XML diff algorithms.  LyX already
supports conversions to XHTML that are reasonably faithful (more on
that some other time), but there's no XML->LyX converter.

I can't contribute much C++ code to LyX, but I could contribute XSLs
to do XML->.lyx conversion, if you point me at documentation on how
the .lyx format and the LyXHTML and XHTML export formats (specifically
what conventions are used to represent LyX elements in XHTML).

>> if you wanted to have bare bones support for git in lyx you would need
>> * commit (saving your changes)
>> * push (share your work)
>> * pull (fetch changes and merge with your work)
>
> I know what I need, but the question was about your workflow.
> In particular, does it make sense in your case to automatically push after 
> commit?

I don't want LyX to be in the business of being a git GUI, but if it
were going to be so we'd need either to always do git commit -a
(ouch), or git add the files LyX knows were touched (risky) then
commit those, or have a git add UI then git commit.  That's either
unsatisfying or a lot of work, so I'd rather LyX stay out of the git
UI business.

What I want is that if git (or whatever) has merged a .lyx file *with*
conflicts, then LyX should be able to display those such that a user
could fix them by normal editing operations in LyX.

>> After testing out the existing svn implementation I think this is actually 
>> simpler to automatically merge with git than to lock files with svn.
>
> Maybe more powerful, but simpler? I have hard time to understand how 
> resolving merge conflicts is _simpler_ than automatical locking part of the 
> document you work on.
> But Ok, we don't agree here, let is sleep.

Locking is simpler until you realize that it causes serious problems
(already discussed).

I don't want to stop you from locking.  I want the option to merge.

Nico
--

Re: APA6 class with LyX?

[Denis J Navas]

"John Kane"  escribió en el mensaje de 
noticias:1355320240.2678.yahoomail...@web162406.mail.bf1.yahoo.com...





From: Uwe Stöhr 
To: obregonma...@gmail.com 
Cc: lyx-users@lists.lyx.org 
Sent: Monday, December 10, 2012 7:34:36 PM
Subject: Re: APA6 class with LyX?


Am 11.12.2012 01:14, schrieb obregonma...@gmail.com:

> Each APA-type journal has its own list of document types that it accepts; 
> these journals are only guided by the APA _style_ conventions. All journals 
> in psychology etc. that I have come across accept tex manuscripts, as long as 
> the tex file contains everything the authors use (i.e., macros) and do not 
> rely on any special latex compiling instructions.

Thanks for the clarification. So a layout for APA  6 is indeed useful.  
However, I won't have time to write it and hope that anybody else can 
volunteer. if you like, I can review the layout.

thanks and regards
Uwe

Hi Uwe,

That would be great. I am not sure that I have enough knowledge to help but I 
certainly would consider it.

One of the reasons I first asked about this was not so much about direct 
submission for publication though that is very important--the APA 5th Manual 
says that over a 1000 non-APA journals use the Manual but because every 
psychology student in North America and from what I see, in at least most of 
the English-speaking psychological world uses it in preparing papers plus 
French speaking students in Québec. There are suggestions here and there that 
the style is used in several (many?) other languages .  This also seems to 
extend to Education, Nursing  and a host of other social science disciplines 
that I am not familiar with.

Essentially a paper for these students must conform pretty much exactly to the 
equivalent of \documentclass[man,12pt]{apa6}.  I don't know know if there is a 
hard-science or math equivalent: Perhaps all undergraduate math student 
assignments need to match AMA formatting guidelines?   

At a rough guess, students in my city with a community college, one small and 
one medium sized unviersty probably submit 5,000 APA formatted papers each 
year. Also, as others have mentioned, with a bit of minor tweaking APA sets the 
style for theses or disertations in a broad range of disciplines.  Come to 
think of it, other disciplinces with less stringent stylistic demands may well 
be very happy with \documentclass[doc,12pt]{apa6}.

So my thought was let's catch them while they are young. From my own experience 
and talking to some current students using APA can be a real hassle and a 
decent apa6 option in LyX would likely be a real crowd pleaser, especially once 
they learned about bibtex.  





Universities here in Nicaragua, use APA style for thesis.

Denis J Navas