Re: [patch] support to set the document-wide text color

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
 It's easter time so here's my easter egg ;-) : support to set the
 document-wide text color.

Your patch assumes that black is equal to no color. But what if a class 
presets a different font color than black? Then the user cannot switch to 
black, AFAICS. So you will need to separate Black and No Color.

Jürgen

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 I thought my apathy would be enough to have Juergen do it, but he won.

I'm making progress, you know ...

Jürgen

revtex4-1

[Ron Siewertsen]

Dear Lyx-Developer-Team,

I have some problems with the implementation of revtex4-1 as a document 
class. On your homepage there is a revtex layout file for download but a 
password is required. In order to get this password one should write to 
this address. I already copied the files from the revtex4-1.zip to my 
miktex folder. Everything works fine with my windows 7 computer but not 
with my windows XP computer.


Thank you very much for possible answers!

Ron Siewertsen

Re: [patch] support to set the document-wide text color

[Pavel Sanda]

Uwe Stöhr wrote:
 It's easter time so here's my easter egg ;-) : support to set the 
 document-wide text color.

regarding the easter eggs, have you read Joost's proposal?
pavel

Visita mi perfil de Netlog

[Dannt Ferrin]

Hola,

He creado una cuenta en Netlog con mis imágenes, vídeos, blogs y eventos. 
Quiero agregarte a mi lista de amistades para que puedas verlo, ¡pero antes 
tienes que registrarte en Netlog! Cuando te conectes podrás crear tu propio 
perfil.

Échale un vistazo:
http://es.netlog.com/go/mailurl/type=invite_1mailid=797319844id=1url=-L2dvL3JlZ2lzdGVyL2lkPTE5NDQ3OTU2MDEmaT10OTE_

Saludos,
Dannt


¿No quieres recibir más invitaciones de tus amigos?
http://es.netlog.com/go/mailurl/type=invite_1mailid=797319844id=2url=-L2dvL25vbWFpbHMvaW52aXRlL2VtYWlsPS1iSGw0TFdSbGRtVnNRR3hwYzNSekxteDVlQzV2Y21jXyZjb2RlPTA1NjA5OTk4JmlkPTE5NDQ3OTU2MDEmaT10OTI_
Don't want to receive invitations from your friends anymore?
http://es.netlog.com/go/mailurl/type=invite_1mailid=797319844id=3url=-aHR0cDovL2VuLm5ldGxvZy5jb20vZ28vbm9tYWlscy9pbnZpdGUvZW1haWw9LWJIbDRMV1JsZG1Wc1FHeHBjM1J6TG14NWVDNXZjbWNfJmNvZGU9MDU2MDk5OTgmaWQ9MTk0NDc5NTYwMSZpPXQ5Mg__

Re: Naming LyxBlogger

[Jack Desert]

El Mon, 29 Mar 2010 09:51:33 +0200
Abdelrazak Younes you...@lyx.org escribió:
 On 03/29/2010 04:37 AM, Jack Desert wrote:
  What is the best name for a piece of software that connects LyX to a 
  WordPress blog, publishing through xml-rpc?
 
  If you have some creative ideas, let's hear them. Here are some suggestions:
 
 
 lyx2wordpress
 
 Unless of course this program can be used for other blog systems.
 
 Abdel.
 
 

lyx2wordpress probably wins the clarity depertment. I'm also looking for 
something with a bit of a shine to it, that rolls off the tongue beautifully, 
that indicates action. 

At this point LyxBlogger only works with WordPress. I am not sure whether it 
will support others in the future.
  


-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

License

[Jack Desert]

Dear Lyx-Devel:

I hereby grant permission for my LyX contributions to by licensed under the GNU 
General Public License, version 2 or later.

Sincerely,

Jack Desert



-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda sa...@lyx.org writes:
 last call for 2.0 feature requests we have reported.

I am really late with this, but I am a bit overwhelmed by work and baby,


 * http://www.lyx.org/trac/ticket/4072
 Default document settings in .layout files


Personnally, I am against this feature as it is presented.
The layout file can already set the latex defaults.

 * http://www.lyx.org/trac/ticket/4286
 Improved statistics (SWeave) support

 JMarc?  btw i'm generally lost whats the sweave status.
 are there some issues you still plan to do
 or just documentation is missing now?

I marked the bug as fixedintrunk and opened new ones for each separate
problem. The milestone is 2.0.0 for now, but we have to discuss this.

Here is what is not yet done in sweave support:

- find a way to read local files. If I have a 
   read.table(foo.txt)
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
http://www.lyx.org/trac/ticket/6623

- pass the noae option to Sweave to make sure it does not ruin our
  font settings.
http://www.lyx.org/trac/ticket/6624

- currently, Sweave reads the files in the encoding of the current
  locale. This fails as soon as the locale is UTF-8 and the document is
  8bit (because the characters themselves are ruined). We need to find a
  way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I have also work that I did not finish to allow creating insets for
verbatim contents (like ERT, but not hardcoded). I would have liked to
finish this before 2.0, but my time is very scarce.

JMarc

Re: r33925 - lyx-devel/trunk/src

[Pavel Sanda]

rgh...@lyx.org wrote:
 Author: rgheck
 Date: Mon Mar 29 22:21:30 2010
 New Revision: 33925
 URL: http://www.lyx.org/trac/changeset/33925
 
 Log:
 Do the translation the right way.
 
 By the way, has anyone noticed that _() returns empty if you call it
 on a string we don't know how to translate? Might it be better if it
 returned the original string?

are you sure about this? i havent ever seen such behaviour.
pavel

Re: r33924 - in lyx-devel/trunk: lib/layouts po src

[Pavel Sanda]

Richard Heck wrote:
 ok, i'll try it. it can always be reverted.

fyi its fine.
pavel

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 I marked the bug as fixedintrunk and opened new ones for each separate
 problem. The milestone is 2.0.0 for now, but we have to discuss this.

something to be done with these two?
http://www.lyx.org/trac/ticket/48
http://www.lyx.org/trac/ticket/6137

 I have also work that I did not finish to allow creating insets for
 verbatim contents (like ERT, but not hardcoded). I would have liked to
 finish this before 2.0, but my time is very scarce.

yes.
pavel

Re: r33925 - lyx-devel/trunk/src

[rgheck]

On 03/30/2010 08:20 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Mon Mar 29 22:21:30 2010
New Revision: 33925
URL: http://www.lyx.org/trac/changeset/33925

Log:
Do the translation the right way.

By the way, has anyone noticed that _() returns empty if you call it
on a string we don't know how to translate? Might it be better if it
returned the original string?
 

are you sure about this? i havent ever seen such behaviour.

   

Yes, but I fixed it later. See r33935.

rh

Python 3

[Pavel Sanda]

hi,

anybody already using python 3 with lyx?
what is the situation with different distros and our compatibility with 3?
(gentoo has 3(.1) still in testing but slowly moving to stable target).

pavel

Re: Patch Submission: LyxBlogger Converters

[rgheck]

Thanks for sending the license statement. I've added you to the credits. 
I've also committed part of this patch, but as I was about to commit the 
whole thing another issue occurred to me. Sorry!


Actually, the first issue is that, especially since 2.0 will (hopefully) 
let the user choose conversion paths, etc, we can go ahead and install 
both the xhtml-blog and html-blog converters. This is particularly 
important in 2.0, it seems to me, since otherwise people who happen to 
have had elyxer installed for use with 1.6.x would not then see that 
they have a new option in 2.0.x.


Or we could, except that the check for elyxer does NOT guarantee that 
lyxblogger will only see output from elyxer. On the contrary, even if 
elyxer is installed, the user might, in 2.0.x, again, override LyX's 
default choice of elyxer as HTML converter. Given that lyxblogger 
expects HTML from elyxer, this could lead to export failures and 
confused users.


That makes me wonder whether lyxblogger might not operate a different 
way, namely, as a LyX--Blog converter that, if it is given a LyX file 
as input, calls elyxer itself. Then we COULD do the check for elyxer 
before registering it as a LyX--Blog converter and all would go 
according to plan.


rh

Re: Enhancement bugs for 2.0

[Gregor GORJANC]

Hi,

Please read bellow.

On 30 March 2010 14:01, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
...
 - find a way to read local files. If I have a
   read.table(foo.txt)
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
 http://www.lyx.org/trac/ticket/6623

I still think that the way I described at [1] is the best it could be done.

 [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

gg

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda sa...@lyx.org writes:

 Jean-Marc Lasgouttes wrote:
 I marked the bug as fixedintrunk and opened new ones for each separate
 problem. The milestone is 2.0.0 for now, but we have to discuss this.

 something to be done with these two?
 http://www.lyx.org/trac/ticket/48

This one I do not know. But I would be surprised to see it magically
fixed. This is probably not very difficult, though.

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

I have no clear idea about this, except that usinf listing is a hack,
probably only to obtain something simpler to use. If I ever finish the
work below, it will become simpler.

 I have also work that I did not finish to allow creating insets for
 verbatim contents (like ERT, but not hardcoded). I would have liked to
 finish this before 2.0, but my time is very scarce.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Gregor GORJANC gregor.gorj...@bfro.uni-lj.si writes:
 On 30 March 2010 14:01, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
 ...
 - find a way to read local files. If I have a
   read.table(foo.txt)
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
 http://www.lyx.org/trac/ticket/6623

 I still think that the way I described at [1] is the best it could be done.

  [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

Yes, it looks indeed the best thing to do. Could you add the description
and your tests in the relevant bug? I am not ignoring you, just running
out of time :) In this case, it is always the task that need more
thinking that get delayed.

JMarc

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
  JMarc?  btw i'm generally lost whats the sweave status.
  are there some issues you still plan to do
  or just documentation is missing now?

one more thing - adding entry to newinlyx20 wiki section, so documentation
is not forgotten. i would add it myself if i had a clue what was exactly
done ;)

pavel

It's time to say goodbye

[Hartmut Haase]

Hi folks,
I'm now 65 years old, stopped my main LyX application last year, and do not 
need LyX 
anymore. I also realized that my advice is not really needed anymore, and 
sometimes 
not even wanted.
Nevertheless I thank all of you, especially Jean-Marc, for your cooperation and 
help 
through the years.
I wish the LyX project much success for the future, and may have a look into it 
now 
and then.
-- 
Viele Grüße,
Hartmut 

Hungerhilfe: http://www.thehungersite.com

Ohne Zensur suchen:
http://suche.amnesty-bergedorf.de/

Das heutige Motto:
You seek to shield those you love, and you like the role of a provider. 

Re: It's time to say goodbye

[rgheck]

On 03/30/2010 12:36 PM, Hartmut Haase wrote:

Hi folks,
I'm now 65 years old, stopped my main LyX application last year, and do not 
need LyX
anymore. I also realized that my advice is not really needed anymore, and 
sometimes
not even wanted.

   
Oh, I wouldn't say that. Your opinions will always be welcome here, 
though of course disagreements are to be expected.



Nevertheless I thank all of you, especially Jean-Marc, for your cooperation and 
help
through the years.
I wish the LyX project much success for the future, and may have a look into it 
now
and then.

   

And best wishes for your future, too.

Richard

Re: r33916 - lyx-devel/trunk/lib/lyx2lyx

[Vincent van Ravesteijn]

rgh...@lyx.org schreef:

Author: rgheck
Date: Mon Mar 29 19:05:21 2010
New Revision: 33916
URL: http://www.lyx.org/trac/changeset/33916

Log:
Use the new put_cmd_in_ert routine in the xymatrix reversion routine.

Vincent, can you check (again) that I didn't break this wiht an off by
one error or something?
  


Thanks Richard,

It seems to be still ok.

Vincent

Re: r33916 - lyx-devel/trunk/lib/lyx2lyx

[rgheck]

On 03/30/2010 12:53 PM, Vincent van Ravesteijn wrote:

rgh...@lyx.org schreef:

Author: rgheck
Date: Mon Mar 29 19:05:21 2010
New Revision: 33916
URL: http://www.lyx.org/trac/changeset/33916

Log:
Use the new put_cmd_in_ert routine in the xymatrix reversion routine.

Vincent, can you check (again) that I didn't break this wiht an off by
one error or something?


Thanks Richard,

It seems to be still ok.


OK, good.

rh

Re: [patch] support to set the document-wide text color

[Uwe Stöhr]

 Your patch assumes that black is equal to no color. But what if a
 class presets a different font color than black? Then the user cannot
 switch to black, AFAICS.

In principle you are right but isn't this only hypothetical? I mean we 
already do the same for the page background color where we say that 
white is equal to no color.
The question is if there really exists a LaTeX class where black is not 
the default font color? If so, the page color handling must be changed too.
I googled a bit and even the presentation classes like beamer and 
powerdot have black = no color.


regards Uwe

Re: It's time to say goodbye

[Alex Fernandez]

Hi Hartmut,

On Tue, Mar 30, 2010 at 5:36 PM, Hartmut Haase hha4...@web.de wrote:
 Nevertheless I thank all of you, especially Jean-Marc, for your cooperation 
 and help
 through the years.
 I wish the LyX project much success for the future, and may have a look into 
 it now
 and then.

Thanks for your help with eLyXer. I have added you to the
acknowledgements for your suggestions regarding translations, it will
be there for the next release (for some reason I forgot to do so at
the moment in version 0.39).

Alex.

Re: It's time to say goodbye

[Uwe Stöhr]

 I'm now 65 years old, stopped my main LyX application last year, and
 do not need LyX anymore. I also realized that my advice is not really
 needed anymore, and sometimes not even wanted.

You helped LyX a lot by your translation work and the bugs you found.
I specially thank you for your outstanding translation work of the 
EmbeddedObjects manual.


I'm aware that we had sometimes disagreements but we always helped you 
with every problem you had with your private publications. Disagreements 
cannot be avoided, especially as we only communicate per mail (missing 
gesture and mimic often leads to unnecessary misunderstandings). They 
are however necessary because only the following discussions move LyX 
forwards.

I therefore hope that you keep us in mind in a positive sense.

 Nevertheless I thank all of you, especially Jean-Marc, for your
 cooperation and help through the years.
 I wish the LyX project much success for the future, and may have a
 look into it now and then.

Best wishes for you and enjoy your retirement with traveling or whatever 
you like.


best regards and many thanks again
Uwe

Re: Issues wrt LyX 2.0 for Windows

[Uwe Stöhr]

 there has been small hint that at least the official installer would
 be somewhat refactorized. please would it be possible that you at
 least _try_ to cooperate on one single code, resulting in a single
 installer for windows?

Hi Joost,

concerning the installers, in the LyX 1.6 cycle I still had the problem 
that I had to maintain the installer alone as you were not accessible 
for longer times. It is therefore important for me to provide an 
installer I fully understand and with the features I need to do that.
I'm nevertheless confident with the collaboration concerning the 
required libraries like spell checker etc. My main point is the 
maintaining of the installer, because it only makes sense if this is 
possible for all of us developers working on Windows.
Looking into your installer code I miss comments and are still not able 
to fix bugs that were reported on the lyx-users list.
As you might have seen on the list in the table metrics threads, I'm not 
a very talented programmer so that it might be my personal problem that 
I'm still not able to maintain your code, so please don't misunderstand 
me - I'm not criticizing you or any anyone else.


I therefore plan to continue my installer. Developers, if you vote not 
to mention my installer anymore on the LyX homepage, then be it. I'm 
only asking to be allowed to keep it in SVN.


Concerning Cmake, I tested it the last days and are not yet convinced 
that this is better than SCons. CMake shows nearly same compilation 
speed but misses the feature to automatically compile the po-files, the 
feature to remerge the po-files, and the feature automatically update 
the Resources folder if a file in SVN's lib folder was changed.
But I think that the build system is a matter of taste because it 
doesn't have an influence on the compiled release versions of the lyx.exe.


Building the installer is already as easy as possible for me: SCons 
already provides everything that is necessary for LyX. I only have to 
copy files of third-party products like ImageMagick to the installer 
build folder when I need to update them. Then I run an NSIS script that 
builds me all 3 installer variants at once.
For a new release I spent most of the time to update the third-party 
programs and to validate that they are working together with each other 
and together with LyX on all Windows platforms (they unfortunately often 
do not). This validation is the real time killer and I don't see a way 
to improve this situation.


regards Uwe

Re: Issues wrt LyX 2.0 for Windows

[Joost Verburg]

On 3/30/2010 3:03 PM, Uwe Stöhr wrote:

I therefore plan to continue my installer. Developers, if you vote not
to mention my installer anymore on the LyX homepage, then be it. I'm
only asking to be allowed to keep it in SVN.


Did you read the thread I started earlier about the Windows 2.0 
installer? I explained that because of the new 2.0 features, it is 
possible to package LyX is a new way that requires much less complicated 
installer code.


My idea is to write a new script for the installer using this approach. 
This shoudn't be done by just one developer, everyone should be 
involved. So there would no longer be a need to have separate sets of 
installers. Also, all developers would be able to maintain it and create 
the official Windows releases. If you want, you could be the person who 
will create the official binaries.


Of course there's not really a point in doing this if there will still 
be separate installers. So the question is whether you are willing to 
join this effort.


Joost

Re: r33934 - in lyx-devel/trunk/src: . support tex2lyx

[Abdelrazak Younes]

On 03/29/2010 11:31 PM, rgh...@lyx.org wrote:

Author: rgheck
Date: Mon Mar 29 23:31:17 2010
New Revision: 33934
URL: http://www.lyx.org/trac/changeset/33934

Log:
Make these const, too. I mean, why not?


Why not making the methods const too then?


-Messages  getMessages(string const  language)
+Messages const  getMessages(string const  language)


Should be:

+Messages const   getMessages(string const   language) const

Don't miss the spaces ;-)

Abdel.

Re: LyX 2.0 / Windows - OK to start the work right now

[Uwe Stöhr]

At first, I apologize the delay in replying to this thread. I support 
your ideas for a unified and new installer, see below:


 Also, some time ago I figured out a way to create completely
 self-contained versions of ImageMagick and Ghostscript, which are in
 the LyX program directory and only used by LyX. They don't require any
 installation or registry keys to be set and therefore work reliably,
 independent of other applications and without administrator
 privileges. This has already been included in all recent installers I
 created.

I also have this already in my installers. There were only reasons why 
my installer requires admin priviledges:

- MiKTeX (no longer an issue since MiKTeX 2.8)
- system sysadmins don't allow to use programs that are not authorized.

I had much trouble in the past with the last issue. there are companies 
and even universities that don't allow the users to use software that is 
not authorized. I will nevertheless ignore this for the next installer 
releases because LyX is free software and it is not our task to care 
about company policies.
I nevertheless propose to provide an installer that allows sysadmins can 
install LyX at once to all computers in their network. I already worked 
on that 2 years ago but my knowledge about maintaining large Windows 
computer networks is still too limited and first tests at my university 
failed.


 Combining these two things, it's possible to create a very simple and
 portable LyX release. We could put all the binaries in a zip file and
 the user can extract this and immediately run LyX with all features.
 The only thing that needs to done manually is to run the installer for
 the LaTeX system and the Metafile to EPS Converter printer if desired.
 And there are the LaTeX classes bundled with LyX that would have to be
 copied to the MiKTeX directory.

No, only the Metafile to EPS printer installation would fail. Since 
MiKTeX 2.8 it is possible to install LaTeX-packages without admin 
permissions. Also since version 2.8, MiKTeX is fully functional when 
being installed without admin privileges.
I fully agree that we should provide a portable LyX installer. The users 
 convinced me that this is a must-have for LyX 2.0 if we would have a 
chance to spread LyX further.


 Of course the user shouldn't have to do this manually; we can also
 build a normal installer. But the point is that the installer code
 would become much more simple. We could write a script that takes the
 zip file release and converts this into a nice NSIS installer. And if
 you need to quickly edit a LyX file on somebody else's computer, the
 zip file itself is also a nice addition.

I propose to provide the portable LyX installer separately from the 
normal installers that write things into the registry. This would ease 
up the maintaining of the installers.


 Even the update installer that Uwe currently maintains manually could
 be automatically generated by comparing the new zip with the previous
 one and excluding unchanged files.

This would really be useful. But how can this be done? Do you plan to 
open all files in SVN's lib folder in text mode and compare there if a 
character was changed compared to the ones in the zip-folder of the last 
released installer? I think that only this solution will work because 
checking only the date of the files doesn't work as the SVN client 
sometimes changes the file date on my PC although the file was not changed.


 This script can be written from scratch with all the relevant people
 involved, so finally we would have a consistent way to release Windows
 binaries. This would allow any developer to generate the official
 builds and there would be only one set of official installers.

If we write it new from scratch and everyone interested is involved, I'm 
on board to use the result as official installer and will discontinue my 
installer. Only this way we would be able to overcome the current 
problem of the maintainability I mentioned in my previous post.
Currently I cannot maintain your current installer and I guess you 
cannot maintain my installer. This state is of course not acceptable in 
the long term.


We should start right now to get it ready for LyX 2.0, but I won't have 
much time for this before April 26. But if you could send your first 
version, I will comment on this as soon as possible and also promise to 
test it.


regards Uwe

Re: Importing doc documents

[Alex Fernandez]

Hi Rob,

On Mon, Mar 29, 2010 at 4:12 PM, Rob Oakes lyx-de...@oak-tree.us wrote:
 LyX already imports/exports to nearly every other format under the sun
 (through the use of external tools, I know), it seems like an oversight to
 leave out the Word processor used by most people.  If you really wanted to
 get fancy, you could try and convert tracked changes and comments from the
 LyX system into MS Word, or vice-versa.  A more robust path for document
 interchange with Word users would go a *long* way to helping LyX adoption.
 I have several colleagues who would love to use it, but need a better way of
 working with MS Word users.

There is already a registered converter for MS Word. It uses HTML
formatting, which Word can import without too much trouble.
Unfortunately eLyXer (using the --html option) is not used for this
task, even though IMHO it produces better output in most cases.

Of course you are never going to get good Math with an HTML
intermediate step, but text and some formatting is readily imported
into Word. Same for OpenOffice.org Writer. This is enough for many
people. If you have any further suggestions please let me know.

Thanks,

Alex.

Re: [patch] support to set the document-wide text color

[Uwe Stöhr]

 regarding the easter eggs, have you read Joost's proposal?

Thanks for the hint. I replied now to his proposal and agreed to create 
a new installer for LyX 2.0 because this would could result in an 
installer that can be maintained by all developers - and this is the 
most important point for me.


regards Uwe

Re: LyX 2.0 / Windows - OK to start the work right now

[Joost Verburg]

On 3/30/2010 3:34 PM, Uwe Stöhr wrote:

At first, I apologize the delay in replying to this thread. I support
your ideas for a unified and new installer, see below:


Great!


If we write it new from scratch and everyone interested is involved, I'm
on board to use the result as official installer and will discontinue my
installer. Only this way we would be able to overcome the current
problem of the maintainability I mentioned in my previous post.
Currently I cannot maintain your current installer and I guess you
cannot maintain my installer. This state is of course not acceptable in
the long term.


I totally agree.


We should start right now to get it ready for LyX 2.0, but I won't have
much time for this before April 26. But if you could send your first
version, I will comment on this as soon as possible and also promise to
test it.


I haven't started working on it yet because I wanted to make sure 
everyone agrees with the approach.


I propose that for alpha 1 we build a simple zip package, since it will 
only be used by advanced users anyway. These users will already have a 
properly configured MiKTeX so they can simply extract the zip file to 
give the development version a try.


For alpha 2 the goal could be to have a basic installer, and then we can 
continue to add extra features such as automatic installation of 
hunspell dictionaries and MyThes thesaurus lists.


Joost

Re: Patch Submission: LyxBlogger Converters

[Jack Desert]

 Thanks for sending the license statement. I've added you to the credits. 

Excellent.
 
 Actually, the first issue is that, especially since 2.0 will (hopefully) 
 let the user choose conversion paths, etc, we can go ahead and install 
 both the xhtml-blog and html-blog converters. This is particularly 
 important in 2.0, it seems to me, since otherwise people who happen to 
 have had elyxer installed for use with 1.6.x would not then see that 
 they have a new option in 2.0.x.

When can we reasonably expect to see this user chooses his own conversion 
paths code? Which contributors are currently working on it? Is there a branch 
somewhere that at least has the GUI so we can see what it looks like?

You do have a valid point about making sure eLyXer users know there's a new kid 
on the block (LyXHTML) in 2.0. I think LyX 2.0 makes that pretty obvious with 
it's big, beautiful preview button that lists LyXHTML as one of its few 
options. Even so, the LyxBlogger xterm window already tells the user which file 
format is being used. It would be trivial yet informative to expand that 
message to: 

'''Based on your input file, you are using the eLyXer format.
LyXBlogger also supports LyX 2.0's internal LyXHTML format.
For more information, see the user's guide at ...'''

and its converse:

'''Based on your input file, you are using the LyXHTML format.
LyXBlogger also supports the eLyXer format.
For more information, see the user's guide at ...'''

 
 Or we could, except that [snip]

Or we could what? Is there a phrase missing here? 

 
 [snip]the check for elyxer does NOT guarantee that lyxblogger will only 
 see output from elyxer. This could lead to export failures and confused users.


To keep latex2html and other converters from being used, LyXBlogger could 
simply parse the html header, looking for the eLyXer style sheet, which always 
points to 
http://www.nongnu.org/elyxer/lyx.css

And  drop an error if it's not found.

'''ERROR: Unsupported Input Type 
Supported inputs are eLyXer and LyXHTML
Your input format appears to be neither of these. 
Proceed anyway? Y (N)'''

That seems quite reasonable. Easy to implement, and gives immediate feedback. 
In fact, I like it so much I'm putting it on my to do list now. 


 That makes me wonder whether lyxblogger might not operate a different 
 way, namely, as a LyX--Blog converter that, if it is given a LyX file 
 as input, calls elyxer itself. Then we COULD do the check for elyxer 
 before registering it as a LyX--Blog converter and all would go 
 according to plan.


Ah, but this would ideed bypass the beauty of the LyX chained converters, and 
add complexity to the front end of LyxBlogger. LyxBlogger would have to deal 
with three input types: xhtml, html, and .lyx. Which brings another question to 
mind: Can the LyX - LyXHTML converter be called from command line? If it can, 
then both converters could theoretically be LyX - blog. I'm not sure I'm 
interested in pursuing that route, but it's something to think about.


CONCLUSION

All said, I still support the idea of only installing one converter by default, 
as in the latest patch I provided (LyxBlogger_Formats_Patch3.diff). With the 
addition of the FORMAT messages and ERROR checking I introduced above, it keeps 
the user informed of his/her options, prevents abuse by TtH, Hevea, and others, 
and maintains elegantly uncluttered export menus. And it would be functional 
_now_, without waiting for the code from the converter-path-chooser which may 
or may not be ready for 2.0. 


-Jack


-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: LyX 2.0 / Windows - OK to start the work right now

[Pavel Sanda]

Joost Verburg wrote:
 If we write it new from scratch and everyone interested is involved, I'm
 on board to use the result as official installer and will discontinue my
...
 I totally agree.

nice. hopefully we can survive the subsequent flames in the technical parts.
if you have some problems with the timing of releases just let me know.

pavel

Re: It's time to say goodbye

[Pavel Sanda]

Hartmut Haase wrote:
 Hi folks,
 I'm now 65 years old,

it is often surprise how different image you build in your
mind when only mail contact is possible...

i remember the double shock when the guy who could be my father
switched from the fluent german speech with Andre to slovak lang
introducing himself as Kornel ;)

 I wish the LyX project much success for the future, and may have a look into 
 it now 
 and then.

as has been already said enjoy whatsoever you plan to do now :)
of course you are welcome in the forthcoming meeting, which
will most probably take place in germany.

good luck :)
pavel

Re: Importing doc documents

[stefano franchi]

On Mon, Mar 29, 2010 at 10:12 AM, Rob Oakes lyx-de...@oak-tree.us wrote:


 With that said, I had a thought.  It seems that I surrounded by happy and
 singing students that are applying for Google code fellowships and
 otherwise
 having hysterics over summer plans.  While it is too late for LyX to submit
 proposals this year, I wonder if trying to get Summer of Code students to
 work on MS Word/LyX converters might make for a good project next year?


That sounds like an excellent idea, although it's too late for this year.
Having spent the better part of a day fighting with lyx--word conversions,
I can only dream of a bare bone converter.
I cannot be a mentor either, but i'd be more than happy to help out any way
I can (testing, etc.)

Stefano




 LyX already imports/exports to nearly every other format under the sun
 (through the use of external tools, I know), it seems like an oversight to
 leave out the Word processor used by most people.  If you really wanted to
 get fancy, you could try and convert tracked changes and comments from the
 LyX system into MS Word, or vice-versa.  A more robust path for document
 interchange with Word users would go a *long* way to helping LyX adoption.
 I have several colleagues who would love to use it, but need a better way
 of
 working with MS Word users.

 I'm not sure what LyX's history with Google's Summer of Code is, but if
 there is any interest, I'd be happy to help with filing applications and
 such.  I'm not sure that I'm qualified to be a mentor, but I could be a
 ruthlessly competent coordinator.

 Cheers,

 Rob Oakes




-- 
__
Stefano Franchi
Department of Philosophy   Ph:   (1) 979 862-2211
Texas AM University Fax: (1) 979 845-0458
College Station, Texas, USA

Re: r33934 - in lyx-devel/trunk/src: . support tex2lyx

[rgheck]

On 03/30/2010 03:27 PM, Abdelrazak Younes wrote:

On 03/29/2010 11:31 PM, rgh...@lyx.org wrote:

Author: rgheck
Date: Mon Mar 29 23:31:17 2010
New Revision: 33934
URL: http://www.lyx.org/trac/changeset/33934

Log:
Make these const, too. I mean, why not?


Why not making the methods const too then?


They're not methods but standalone functions. ;-)

rh

Re: Importing doc documents

[stefano franchi]

On Tue, Mar 30, 2010 at 2:36 PM, Alex Fernandez alejandro...@gmail.comwrote:

 Hi Rob,

 There is already a registered converter for MS Word. It uses HTML
 formatting, which Word can import without too much trouble.
 Unfortunately eLyXer (using the --html option) is not used for this
 task, even though IMHO it produces better output in most cases.

 In my, very recent, experience, there are several converters Lyx-Word, but
no *robust* one.
Problems I encountered yesterday trying to convert a relatively simple
15-pages lyx  file that compiled perfectly to pdf into word:

-- all character sequences including ligatures (ff, ffi, etc) disappearing,
silently, from the output

--- all accented characters being converted into the wrong glyphs

--- tables mangled beyond recognition, or simply (again, silently)
suppressed from the output

--- images missing, or distorted, or resized to full page, etcetera

-- many other problems that I now (happily) forget


I tried everything I could find: the lyx html(word) export, html export, and
oolatex (all variations of htlatex, I seem to remember), hevea, tth,
latex2rtf, elixer
I eventually managed to produce something barely acceptable, but it was a
nightmare.


S.







 Of course you are never going to get good Math with an HTML
 intermediate step, but text and some formatting is readily imported
 into Word. Same for OpenOffice.org Writer. This is enough for many
 people. If you have any further suggestions please let me know.

 Thanks,

 Alex.




-- 
__
Stefano Franchi
Department of Philosophy   Ph:   (1) 979 862-2211
Texas AM University Fax: (1) 979 845-0458
College Station, Texas, USA

Re: Patch Submission: LyxBlogger Converters

[rgheck]

On 03/30/2010 04:15 PM, Jack Desert wrote:



Actually, the first issue is that, especially since 2.0 will (hopefully)
let the user choose conversion paths, etc, we can go ahead and install
both the xhtml-blog and html-blog converters. This is particularly
important in 2.0, it seems to me, since otherwise people who happen to
have had elyxer installed for use with 1.6.x would not then see that
they have a new option in 2.0.x.
 

When can we reasonably expect to see this user chooses his own conversion 
paths code? Which contributors are currently working on it? Is there a branch 
somewhere that at least has the GUI so we can see what it looks like?

   
Jurgen did a bunch of work on it but ran into a problem. I've told him 
I'll help him sort it out and did some of the necessary background work. 
But then he got busy and otherwise distracted, so it's kind of on hold 
for the moment. But I think we both really want to get it into 2.0. If 
not, then it would almost certainly have to wait for 2.0, due to file 
format issues.



Or we could, except that [snip]
 

Or we could what? Is there a phrase missing here?

   
I think I meant: We could install lyxblogger as an html-blog converter, 
but...


   

[snip]the check for elyxer does NOT guarantee that lyxblogger will only
see output from elyxer. This could lead to export failures and confused users.
 


To keep latex2html and other converters from being used, LyXBlogger could 
simply parse the html header, looking for the eLyXer style sheet, which always 
points to
 http://www.nongnu.org/elyxer/lyx.css

And  drop an error if it's not found.

 '''ERROR: Unsupported Input Type
 Supported inputs are eLyXer and LyXHTML
 Your input format appears to be neither of these.
 Proceed anyway? Y (N)'''

That seems quite reasonable. Easy to implement, and gives immediate feedback. 
In fact, I like it so much I'm putting it on my to do list now.

   
This is all true, though note that, from within LyX itself, you can't 
ask the question Proceed anyway? There's no mechanism for LyX to 
communicate with the running script. Indeed, if you tried to ask such a 
question, the script would freeze, waiting for input. So you either 
proceed or you don't.


I do not mean any of this as a criticism of lyxblogger. My point is just 
that the way LyX's whole converter mechanism is designed presently makes 
integrating it somewhat messy. Each converter defines a path in a graph, 
and the question what conversions are possible? then becomes the 
question: Is there a path from format A to format B? You can get some 
pretty wild conversion paths sometimes---there are actually some weird 
issues that result from elyxer's being a LyX--HTML converter---but it 
is a very flexible system. My ponit is that depends upon converters 
being able to convert between the formats that they advertise as being 
able to convert between. So, to totally overstate the point, from LyX's 
point of view what this means is that lyxblogger isn't really an html to 
blog converter. It doesn't even purport to work with arbitrary HTML 
files. So installing it as an html to blog converter means installing an 
html to blog converter that we know won't work if someone chooses to 
override the choice of elyxer and instead to go lyx-latex-html.


Right now, that isn't possible, so the sort of patch you provided would 
work perfectly fine in 1.6.6. I'd suggest you prepare a patch, doing 
just the elyxer part, for branch, post it, and see if we get approval 
from Jurgen. For 2.0, it would also work as things presently are. But 
trunk isn't really usable right now, except by the very brave or very 
stupid, so there's no rush. I'd propose that we wait on this for the 
time being and see what happens with the choose your converter stuff. 
Once we get near beta, we will do something.



That makes me wonder whether lyxblogger might not operate a different
way, namely, as a LyX--Blog converter that, if it is given a LyX file
as input, calls elyxer itself. Then we COULD do the check for elyxer
before registering it as a LyX--Blog converter and all would go
according to plan.
 


Ah, but this would ideed bypass the beauty of the LyX chained converters,

   
Yes, I know, but maybe the previous explanation makes the point of the 
suggestion clearer.



and add complexity to the front end of LyxBlogger. LyxBlogger would have to 
deal with three input types: xhtml, html, and .lyx.

   

Not pretty, I know.


Which brings another question to mind: Can the LyX -  LyXHTML converter be 
called from command line?

   

Yes, this is possible: lyx -e xhtml file.lyx.


If it can, then both converters could theoretically be LyX -  blog. I'm not 
sure I'm interested in pursuing that route, but it's something to think about.

   
Worth thinking about, yes. Not clear how much benefit there is there, 
but maybe some.


rh

Re: I can´t run lyx 2.0.0 alpha 1

[Marcelo Acuña]

  I have download alpha 1,
  configure, compile and install without problem.
  But when I run it get:
 
  lyx-2.0.0.a1: symbol lookup error:
 lyx-2.0.0.a1:
  undefined
  symbol: _ZN11QVectorData4freeEPS_i
 
  I have debian lenny with g++ 4.3.2, qt 4.6.2.
 
  Regards
  Usually, you use a different run-time version of
 Qt as the
  one you used in the compilation.
 
  Vincent
  
 Have you done a system update after building LyX?
 Then you've linked against a Qt version which is not
 available any more on your system after your update.
 
 Peter

 Problem solved.
 I make an update before build Lyx, but something no work well and libs from 
previous version still remained.
 I corrected the problem and now all work ok.
 Thanks!
Marcelo


  Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.


http://ar.mujer.yahoo.com/cocina/

Re: [patch] fix #3865 - support to change the font color for greyed-out notes

[Uwe Stöhr]

I wrote:


Attached is a patch for
http://www.lyx.org/trac/ticket/3865
This would of course be a fileformat change.


An improved version of the patch is in.

There is one remaining problem: When opening a file where the font color is set as in the attached 
file. The color is not displayed in LyX. The strange thing is that the font is correctly displayed 
in the document font settings dialog.


The problem is that
lcolor.setColor()
in BufferParams::readToken()
is ignored.
This bug turns out to be a general one that is also present in LyX 1.6.6svn:
http://www.lyx.org/trac/ticket/6626

regards Uwe


ColorTest3.lyx
Description: application/lyx

Re: Importing doc documents

[Alex Fernandez]

Hi Stefano,

On Tue, Mar 30, 2010 at 10:18 PM, stefano franchi
fran...@philosophy.tamu.edu wrote:
 In my, very recent, experience, there are several converters Lyx-Word, but
 no *robust* one.
 Problems I encountered yesterday trying to convert a relatively simple
 15-pages lyx  file that compiled perfectly to pdf into word:

Please send your document to me, or to the eLyXer user list. You can
lorem-ipsumize it (using the loremipsumize.py script included with
eLyXer) if needed. I will do my best to make eLyXer output acceptable
HTML code.

 I tried everything I could find: the lyx html(word) export, html export, and
 oolatex (all variations of htlatex, I seem to remember), hevea, tth,
 latex2rtf, elixer
 I eventually managed to produce something barely acceptable, but it was a
 nightmare.

Did you get better results with eLyXer, or was it just the same as the
others? Just curious.

Alex.

new regression bug in LyX 2.0svn

[Uwe Stöhr]

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

regards Uwe

[patch] support for Turkmen

[Uwe Stöhr]

The attached patch adds support for Turkmen
(http://en.wikipedia.org/wiki/Turkmen_language)
This will be a fileformat change.

regards Uwe
Index: development/FORMAT
===
--- development/FORMAT	(revision 33963)
+++ development/FORMAT	(working copy)
@@ -2,6 +2,9 @@
 ---
 
 2010-03-31 Uwe Stöhr uwesto...@web.de
+	* Format incremented to 383: support for Turkmen
+
+2010-03-31 Uwe Stöhr uwesto...@web.de
 	* Format incremented to 382: support to change the font color
 	for greyed-out notes
 
Index: lib/languages
===
--- lib/languages	(revision 33963)
+++ lib/languages	(working copy)
@@ -82,6 +82,7 @@
 swedish swedish	Swedish	false  iso8859-15 sv_SE	 
 thaithai	Thai		false  tis620-0   th_TH	 \usepackage{thswitch}
 turkish turkish	Turkish	false  iso8859-9  tr_TR	 
+turkmen turkmen	Turkmen	false  utf8   tk_TM	 
 ukrainian   ukrainian	Ukrainian	false  koi8-u uk_UA	 
 uppersorbianuppersorbian	Upper Sorbian	false  iso8859-2  hsb_DE	 
 vietnamese  vietnam	Vietnamese	false  utf8   vi_VN	 
Index: lib/lyx2lyx/lyx_2_0.py
===
--- lib/lyx2lyx/lyx_2_0.py	(revision 33963)
+++ lib/lyx2lyx/lyx_2_0.py	(working copy)
@@ -1376,6 +1376,23 @@
+ ' {\\textcolor{note_fontcolor}\\bgroup}{\\egroup}\n')
 
 
+def revert_turkmen(document):
+Set language Turkmen to English 
+i = 0 
+if document.language == turkmen: 
+document.language = english 
+i = find_token(document.header, \\language, 0) 
+if i != -1: 
+document.header[i] = \\language english 
+j = 0 
+while True: 
+j = find_token(document.body, \\lang turkmen, j) 
+if j == -1: 
+return 
+document.body[j] = document.body[j].replace(\\lang turkmen, \\lang english) 
+j = j + 1 
+
+
 ##
 # Conversion hub
 #
@@ -1417,10 +1434,12 @@
[379, [convert_math_output]],
[380, []],
[381, []],
-   [382, []]
+   [382, []],
+   [383, []]
   ]
 
-revert =  [[381, [revert_notefontcolor]],
+revert =  [[382, [revert_turkmen]],
+   [381, [revert_notefontcolor]],
[380, [revert_equalspacing_xymatrix]],
[379, [revert_inset_preview]],
[378, [revert_math_output]],
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 33963)
+++ src/Buffer.cpp	(working copy)
@@ -126,7 +126,7 @@
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 382; // uwestoehr: support to change font color for greyed-out notes
+int const LYX_FORMAT = 383; // uwestoehr: support for Turkmen
 
 typedef mapstring, bool DepClean;
 typedef mapdocstring, pairInsetLabel const *, Buffer::References  RefCache;
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 33963)
+++ src/BufferParams.cpp	(working copy)
@@ -1210,10 +1210,12 @@
 		// viet = string::npos when not found
 		// the same is for all other languages that are not directly supported by
 		// babel, but where LaTeX-packages add babel support.
-		// this is currently the case for Latvian, Lithuanian, and Mongolian
+		// this is currently the case for Latvian, Lithuanian, Mongolian
+		// and Turkmen
 		size_t latvian = language_options.str().find(latvian);
 		size_t lithu = language_options.str().find(lithuanian);
 		size_t mongo = language_options.str().find(mongolian);
+		size_t turkmen = language_options.str().find(turkmen);
 		// if Japanese is used, babel must directly be loaded
 		// with language options, not in the class options, see
 		// http://www.lyx.org/trac/ticket/4597#c4
@@ -1221,7 +1223,7 @@
 		if (lyxrc.language_global_options  !language_options.str().empty()
 			 viet == string::npos  japan == string::npos
 			 latvian == string::npos  lithu == string::npos
-			 mongo == string::npos)
+			 mongo == string::npos  turkmen == string::npos)
 			clsoptions  language_options.str()  ',';
 	}
 
@@ -2103,17 +2105,20 @@
 	// viet = string::npos when not found
 	// the same is for all other languages that are not directly supported by
 	// babel, but where LaTeX-packages add babel support.
-	// this is currently the case for Latvian, Lithuanian, and Mongolian
+	// this is currently the case for Latvian, Lithuanian, Mongolian
+	// and Turkmen
 	size_t latvian = lang_opts.find(latvian);
 	size_t lithu = lang_opts.find(lithuanian);
 	size_t mongo = lang_opts.find(mongolian);
+	size_t turkmen = lang_opts.find(turkmen);
 	// If Japanese is used, babel must directly be loaded with the
 	// language options, see
 	// http://www.lyx.org/trac/ticket/4597#c4
 	size_t japan = 

Re: new regression bug in LyX 2.0svn

[Julien Rioux]

On 30/03/2010 9:22 PM, Uwe Stöhr wrote:

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

regards Uwe



Isn't this the same as http://www.lyx.org/trac/ticket/6519 ?

--
Julien

revtex 4-1 layout password

[Anton Starikov]

Hi,

I would like to test new revtex4-1 layout, can I get password for it?

Thank you, 

Anton Starikov

[patch] Dot - Image formats

[Julien Rioux]

Hi List,

I was pleasantly surprised today when I realised I could directly input 
a .dot graph file into LyX and LyX would do the conversion 
automatically. No need to set up converters!


However the quality of the postscript output was poor. So I went and 
checked: there was no dot-eps converter, only a dot-pdf one.


LyX knows of a chain to convert pdf-eps, but along the way quality was 
lost somehow. Therefore I suggest the following patch, using the dot 
utility to perform all dot-(something else) conversions. For my setup, 
the output definitely has better quality in this way.


Regards,
Julien
Index: lib/configure.py
===
--- lib/configure.py(revision 33961)
+++ lib/configure.py(working copy)
@@ -757,8 +757,13 @@
 \converter agrppmgracebat -hardcopy -printfile $$o -hdevice 
PNM $$i 2/dev/null  ''',
 ''])
 #
-checkProg('a Dot - PDF converter', ['dot -Tpdf $$i -o $$o'],
-rc_entry = [ r'\converter dotpdf%%   '])
+checkProg('a Dot - Image converter', ['dot'],
+rc_entry = [
+r'''\converter dotepsdot -Teps $$i -o $$o

+\converter dotjpgdot -Tjpg $$i -o $$o
+\converter dotpdfdot -Tpdf $$i -o $$o
+\converter dotpngdot -Tpng $$i -o $$o''',
+''])
 #
 checkProg('a Dia - PNG converter', ['dia -e $$o -t png $$i'],
 rc_entry = [ r'\converter diapng%%   '])

Re: [patch] support to set the document-wide text color

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
> It's easter time so here's my easter egg ;-) : support to set the
> document-wide text color.

Your patch assumes that black is equal to no color. But what if a class 
presets a different font color than black? Then the user cannot switch to 
black, AFAICS. So you will need to separate "Black" and "No Color".

Jürgen

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> I thought my apathy would be enough to have Juergen do it, but he won.

I'm making progress, you know ...

Jürgen

revtex4-1

[Ron Siewertsen]

Dear Lyx-Developer-Team,

I have some problems with the implementation of revtex4-1 as a document 
class. On your homepage there is a revtex layout file for download but a 
password is required. In order to get this password one should write to 
this address. I already copied the files from the revtex4-1.zip to my 
miktex folder. Everything works fine with my windows 7 computer but not 
with my windows XP computer.


Thank you very much for possible answers!

Ron Siewertsen

Re: [patch] support to set the document-wide text color

[Pavel Sanda]

Uwe Stöhr wrote:
> It's easter time so here's my easter egg ;-) : support to set the 
> document-wide text color.

regarding the easter eggs, have you read Joost's proposal?
pavel

Visita mi perfil de Netlog

[Dannt Ferrin]

Hola,

He creado una cuenta en Netlog con mis imágenes, vídeos, blogs y eventos. 
Quiero agregarte a mi lista de amistades para que puedas verlo, ¡pero antes 
tienes que registrarte en Netlog! Cuando te conectes podrás crear tu propio 
perfil.

Échale un vistazo:
http://es.netlog.com/go/mailurl/type=invite_1=797319844=1=-L2dvL3JlZ2lzdGVyL2lkPTE5NDQ3OTU2MDEmaT10OTE_

Saludos,
Dannt


¿No quieres recibir más invitaciones de tus amigos?
http://es.netlog.com/go/mailurl/type=invite_1=797319844=2=-L2dvL25vbWFpbHMvaW52aXRlL2VtYWlsPS1iSGw0TFdSbGRtVnNRR3hwYzNSekxteDVlQzV2Y21jXyZjb2RlPTA1NjA5OTk4JmlkPTE5NDQ3OTU2MDEmaT10OTI_
Don't want to receive invitations from your friends anymore?
http://es.netlog.com/go/mailurl/type=invite_1=797319844=3=-aHR0cDovL2VuLm5ldGxvZy5jb20vZ28vbm9tYWlscy9pbnZpdGUvZW1haWw9LWJIbDRMV1JsZG1Wc1FHeHBjM1J6TG14NWVDNXZjbWNfJmNvZGU9MDU2MDk5OTgmaWQ9MTk0NDc5NTYwMSZpPXQ5Mg__

Re: Naming LyxBlogger

[Jack Desert]

El Mon, 29 Mar 2010 09:51:33 +0200
Abdelrazak Younes  escribió:
> On 03/29/2010 04:37 AM, Jack Desert wrote:
> > What is the best name for a piece of software that connects LyX to a 
> > WordPress blog, publishing through xml-rpc?
> >
> > If you have some creative ideas, let's hear them. Here are some suggestions:
> >
> 
> lyx2wordpress
> 
> Unless of course this program can be used for other blog systems.
> 
> Abdel.
> 
> 

lyx2wordpress probably wins the clarity depertment. I'm also looking for 
something with a bit of a shine to it, that rolls off the tongue beautifully, 
that indicates action. 

At this point LyxBlogger only works with WordPress. I am not sure whether it 
will support others in the future.
  


-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

License

[Jack Desert]

Dear Lyx-Devel:

I hereby grant permission for my LyX contributions to by licensed under the GNU 
General Public License, version 2 or later.

Sincerely,

Jack Desert



-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda  writes:
> last call for 2.0 feature requests we have reported.

I am really late with this, but I am a bit overwhelmed by work and baby,

>
> * http://www.lyx.org/trac/ticket/4072
> Default document settings in .layout files
>

Personnally, I am against this feature as it is presented.
The layout file can already set the latex defaults.

> * http://www.lyx.org/trac/ticket/4286
> Improved statistics (SWeave) support
>
> JMarc?  btw i'm generally lost whats the sweave status.
> are there some issues you still plan to do
> or just documentation is missing now?

I marked the bug as fixedintrunk and opened new ones for each separate
problem. The milestone is 2.0.0 for now, but we have to discuss this.

Here is what is not yet done in sweave support:

- find a way to read local files. If I have a 
   read.table("foo.txt")
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
http://www.lyx.org/trac/ticket/6623

- pass the "noae" option to Sweave to make sure it does not ruin our
  font settings.
http://www.lyx.org/trac/ticket/6624

- currently, Sweave reads the files in the encoding of the current
  locale. This fails as soon as the locale is UTF-8 and the document is
  8bit (because the characters themselves are ruined). We need to find a
  way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I have also work that I did not finish to allow creating insets for
verbatim contents (like ERT, but not hardcoded). I would have liked to
finish this before 2.0, but my time is very scarce.

JMarc

Re: r33925 - lyx-devel/trunk/src

[Pavel Sanda]

rgh...@lyx.org wrote:
> Author: rgheck
> Date: Mon Mar 29 22:21:30 2010
> New Revision: 33925
> URL: http://www.lyx.org/trac/changeset/33925
> 
> Log:
> Do the translation the right way.
> 
> By the way, has anyone noticed that _() returns empty if you call it
> on a string we don't know how to translate? Might it be better if it
> returned the original string?

are you sure about this? i havent ever seen such behaviour.
pavel

Re: r33924 - in lyx-devel/trunk: lib/layouts po src

[Pavel Sanda]

Richard Heck wrote:
> ok, i'll try it. it can always be reverted.

fyi its fine.
pavel

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> I marked the bug as fixedintrunk and opened new ones for each separate
> problem. The milestone is 2.0.0 for now, but we have to discuss this.

something to be done with these two?
http://www.lyx.org/trac/ticket/48
http://www.lyx.org/trac/ticket/6137

> I have also work that I did not finish to allow creating insets for
> verbatim contents (like ERT, but not hardcoded). I would have liked to
> finish this before 2.0, but my time is very scarce.

yes.
pavel

Re: r33925 - lyx-devel/trunk/src

[rgheck]

On 03/30/2010 08:20 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Mon Mar 29 22:21:30 2010
New Revision: 33925
URL: http://www.lyx.org/trac/changeset/33925

Log:
Do the translation the right way.

By the way, has anyone noticed that _() returns empty if you call it
on a string we don't know how to translate? Might it be better if it
returned the original string?
 

are you sure about this? i havent ever seen such behaviour.

   

Yes, but I fixed it later. See r33935.

rh

Python 3

[Pavel Sanda]

hi,

anybody already using python 3 with lyx?
what is the situation with different distros and our compatibility with 3?
(gentoo has 3(.1) still in testing but slowly moving to stable target).

pavel

Re: Patch Submission: LyxBlogger Converters

[rgheck]

Thanks for sending the license statement. I've added you to the credits. 
I've also committed part of this patch, but as I was about to commit the 
whole thing another issue occurred to me. Sorry!


Actually, the first issue is that, especially since 2.0 will (hopefully) 
let the user choose conversion paths, etc, we can go ahead and install 
both the xhtml->blog and html->blog converters. This is particularly 
important in 2.0, it seems to me, since otherwise people who happen to 
have had elyxer installed for use with 1.6.x would not then see that 
they have a new option in 2.0.x.


Or we could, except that the check for elyxer does NOT guarantee that 
lyxblogger will only see output from elyxer. On the contrary, even if 
elyxer is installed, the user might, in 2.0.x, again, override LyX's 
default choice of elyxer as HTML converter. Given that lyxblogger 
expects HTML from elyxer, this could lead to export failures and 
confused users.


That makes me wonder whether lyxblogger might not operate a different 
way, namely, as a LyX-->Blog converter that, if it is given a LyX file 
as input, calls elyxer itself. Then we COULD do the check for elyxer 
before registering it as a LyX-->Blog converter and all would go 
according to plan.


rh

Re: Enhancement bugs for 2.0

[Gregor GORJANC]

Hi,

Please read bellow.

On 30 March 2010 14:01, Jean-Marc Lasgouttes  wrote:
...
> - find a way to read local files. If I have a
>   read.table("foo.txt")
>  in the file, it will fail because R is ran from the tmp dir. Since
>   there is no PATH-like support in R, I do not know how to solve the
>   problem. I should try to contact R developers about this
> http://www.lyx.org/trac/ticket/6623

I still think that the way I described at [1] is the best it could be done.

 [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

gg

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda  writes:

> Jean-Marc Lasgouttes wrote:
>> I marked the bug as fixedintrunk and opened new ones for each separate
>> problem. The milestone is 2.0.0 for now, but we have to discuss this.
>
> something to be done with these two?
> http://www.lyx.org/trac/ticket/48

This one I do not know. But I would be surprised to see it magically
fixed. This is probably not very difficult, though.

> http://www.lyx.org/trac/ticket/6137

I have no clear idea about this, except that usinf listing is a hack,
probably only to obtain something simpler to use. If I ever finish the
work below, it will become simpler.

>> I have also work that I did not finish to allow creating insets for
>> verbatim contents (like ERT, but not hardcoded). I would have liked to
>> finish this before 2.0, but my time is very scarce.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Gregor GORJANC  writes:
> On 30 March 2010 14:01, Jean-Marc Lasgouttes  wrote:
> ...
>> - find a way to read local files. If I have a
>>   read.table("foo.txt")
>>  in the file, it will fail because R is ran from the tmp dir. Since
>>   there is no PATH-like support in R, I do not know how to solve the
>>   problem. I should try to contact R developers about this
>> http://www.lyx.org/trac/ticket/6623
>
> I still think that the way I described at [1] is the best it could be done.
>
>  [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

Yes, it looks indeed the best thing to do. Could you add the description
and your tests in the relevant bug? I am not ignoring you, just running
out of time :) In this case, it is always the task that need more
thinking that get delayed.

JMarc

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> > JMarc?  btw i'm generally lost whats the sweave status.
> > are there some issues you still plan to do
> > or just documentation is missing now?

one more thing - adding entry to newinlyx20 wiki section, so documentation
is not forgotten. i would add it myself if i had a clue what was exactly
done ;)

pavel

It's time to say goodbye

[Hartmut Haase]

Hi folks,
I'm now 65 years old, stopped my main LyX application last year, and do not 
need LyX 
anymore. I also realized that my advice is not really needed anymore, and 
sometimes 
not even wanted.
Nevertheless I thank all of you, especially Jean-Marc, for your cooperation and 
help 
through the years.
I wish the LyX project much success for the future, and may have a look into it 
now 
and then.
-- 
Viele Grüße,
Hartmut 

Hungerhilfe: http://www.thehungersite.com

Ohne Zensur suchen:
http://suche.amnesty-bergedorf.de/

Das heutige Motto:
You seek to shield those you love, and you like the role of a provider. 

Re: It's time to say goodbye

[rgheck]

On 03/30/2010 12:36 PM, Hartmut Haase wrote:

Hi folks,
I'm now 65 years old, stopped my main LyX application last year, and do not 
need LyX
anymore. I also realized that my advice is not really needed anymore, and 
sometimes
not even wanted.

   
Oh, I wouldn't say that. Your opinions will always be welcome here, 
though of course disagreements are to be expected.



Nevertheless I thank all of you, especially Jean-Marc, for your cooperation and 
help
through the years.
I wish the LyX project much success for the future, and may have a look into it 
now
and then.

   

And best wishes for your future, too.

Richard

Re: r33916 - lyx-devel/trunk/lib/lyx2lyx

[Vincent van Ravesteijn]

rgh...@lyx.org schreef:

Author: rgheck
Date: Mon Mar 29 19:05:21 2010
New Revision: 33916
URL: http://www.lyx.org/trac/changeset/33916

Log:
Use the new put_cmd_in_ert routine in the xymatrix reversion routine.

Vincent, can you check (again) that I didn't break this wiht an off by
one error or something?
  


Thanks Richard,

It seems to be still ok.

Vincent

Re: r33916 - lyx-devel/trunk/lib/lyx2lyx

[rgheck]

On 03/30/2010 12:53 PM, Vincent van Ravesteijn wrote:

rgh...@lyx.org schreef:

Author: rgheck
Date: Mon Mar 29 19:05:21 2010
New Revision: 33916
URL: http://www.lyx.org/trac/changeset/33916

Log:
Use the new put_cmd_in_ert routine in the xymatrix reversion routine.

Vincent, can you check (again) that I didn't break this wiht an off by
one error or something?


Thanks Richard,

It seems to be still ok.


OK, good.

rh

Re: [patch] support to set the document-wide text color

[Uwe Stöhr]

> Your patch assumes that black is equal to no color. But what if a
> class presets a different font color than black? Then the user cannot
> switch to black, AFAICS.

In principle you are right but isn't this only hypothetical? I mean we 
already do the same for the page background color where we say that 
white is equal to no color.
The question is if there really exists a LaTeX class where black is not 
the default font color? If so, the page color handling must be changed too.
I googled a bit and even the presentation classes like beamer and 
powerdot have "black = no color".


regards Uwe

Re: It's time to say goodbye

[Alex Fernandez]

Hi Hartmut,

On Tue, Mar 30, 2010 at 5:36 PM, Hartmut Haase  wrote:
> Nevertheless I thank all of you, especially Jean-Marc, for your cooperation 
> and help
> through the years.
> I wish the LyX project much success for the future, and may have a look into 
> it now
> and then.

Thanks for your help with eLyXer. I have added you to the
acknowledgements for your suggestions regarding translations, it will
be there for the next release (for some reason I forgot to do so at
the moment in version 0.39).

Alex.

Re: It's time to say goodbye

[Uwe Stöhr]

> I'm now 65 years old, stopped my main LyX application last year, and
> do not need LyX anymore. I also realized that my advice is not really
> needed anymore, and sometimes not even wanted.

You helped LyX a lot by your translation work and the bugs you found.
I specially thank you for your outstanding translation work of the 
EmbeddedObjects manual.


I'm aware that we had sometimes disagreements but we always helped you 
with every problem you had with your private publications. Disagreements 
cannot be avoided, especially as we only communicate per mail (missing 
gesture and mimic often leads to unnecessary misunderstandings). They 
are however necessary because only the following discussions move LyX 
forwards.

I therefore hope that you keep us in mind in a positive sense.

> Nevertheless I thank all of you, especially Jean-Marc, for your
> cooperation and help through the years.
> I wish the LyX project much success for the future, and may have a
> look into it now and then.

Best wishes for you and enjoy your retirement with traveling or whatever 
you like.


best regards and many thanks again
Uwe

Re: Issues wrt LyX 2.0 for Windows

[Uwe Stöhr]

>> there has been small hint that at least the official installer would
>> be somewhat refactorized. please would it be possible that you at
>> least _try_ to cooperate on one single code, resulting in a single
>> installer for windows?

Hi Joost,

concerning the installers, in the LyX 1.6 cycle I still had the problem 
that I had to maintain the installer alone as you were not accessible 
for longer times. It is therefore important for me to provide an 
installer I fully understand and with the features I need to do that.
I'm nevertheless confident with the collaboration concerning the 
required libraries like spell checker etc. My main point is the 
maintaining of the installer, because it only makes sense if this is 
possible for all of us developers working on Windows.
Looking into your installer code I miss comments and are still not able 
to fix bugs that were reported on the lyx-users list.
As you might have seen on the list in the table metrics threads, I'm not 
a very talented programmer so that it might be my personal problem that 
I'm still not able to maintain your code, so please don't misunderstand 
me - I'm not criticizing you or any anyone else.


I therefore plan to continue my installer. Developers, if you vote not 
to mention my installer anymore on the LyX homepage, then be it. I'm 
only asking to be allowed to keep it in SVN.


Concerning Cmake, I tested it the last days and are not yet convinced 
that this is better than SCons. CMake shows nearly same compilation 
speed but misses the feature to automatically compile the po-files, the 
feature to remerge the po-files, and the feature automatically update 
the "Resources" folder if a file in SVN's "lib" folder was changed.
But I think that the build system is a matter of taste because it 
doesn't have an influence on the compiled release versions of the lyx.exe.


Building the installer is already as easy as possible for me: SCons 
already provides everything that is necessary for LyX. I only have to 
copy files of third-party products like ImageMagick to the installer 
build folder when I need to update them. Then I run an NSIS script that 
builds me all 3 installer variants at once.
For a new release I spent most of the time to update the third-party 
programs and to validate that they are working together with each other 
and together with LyX on all Windows platforms (they unfortunately often 
do not). This validation is the real time killer and I don't see a way 
to improve this situation.


regards Uwe

Re: Issues wrt LyX 2.0 for Windows

[Joost Verburg]

On 3/30/2010 3:03 PM, Uwe Stöhr wrote:

I therefore plan to continue my installer. Developers, if you vote not
to mention my installer anymore on the LyX homepage, then be it. I'm
only asking to be allowed to keep it in SVN.


Did you read the thread I started earlier about the Windows 2.0 
installer? I explained that because of the new 2.0 features, it is 
possible to package LyX is a new way that requires much less complicated 
installer code.


My idea is to write a new script for the installer using this approach. 
This shoudn't be done by just one developer, everyone should be 
involved. So there would no longer be a need to have separate sets of 
installers. Also, all developers would be able to maintain it and create 
the official Windows releases. If you want, you could be the person who 
will create the official binaries.


Of course there's not really a point in doing this if there will still 
be separate installers. So the question is whether you are willing to 
join this effort.


Joost

Re: r33934 - in lyx-devel/trunk/src: . support tex2lyx

[Abdelrazak Younes]

On 03/29/2010 11:31 PM, rgh...@lyx.org wrote:

Author: rgheck
Date: Mon Mar 29 23:31:17 2010
New Revision: 33934
URL: http://www.lyx.org/trac/changeset/33934

Log:
Make these const, too. I mean, why not?


Why not making the methods const too then?


-Messages&  getMessages(string const&  language)
+Messages const&  getMessages(string const&  language)


Should be:

+Messages const &  getMessages(string const &  language) const

Don't miss the spaces ;-)

Abdel.

Re: LyX 2.0 / Windows - OK to start the work right now

[Uwe Stöhr]

At first, I apologize the delay in replying to this thread. I support 
your ideas for a unified and new installer, see below:


> Also, some time ago I figured out a way to create completely
> self-contained versions of ImageMagick and Ghostscript, which are in
> the LyX program directory and only used by LyX. They don't require any
> installation or registry keys to be set and therefore work reliably,
> independent of other applications and without administrator
> privileges. This has already been included in all recent installers I
> created.

I also have this already in my installers. There were only reasons why 
my installer requires admin priviledges:

- MiKTeX (no longer an issue since MiKTeX 2.8)
- system sysadmins don't allow to use programs that are not authorized.

I had much trouble in the past with the last issue. there are companies 
and even universities that don't allow the users to use software that is 
not authorized. I will nevertheless ignore this for the next installer 
releases because LyX is free software and it is not our task to care 
about company policies.
I nevertheless propose to provide an installer that allows sysadmins can 
install LyX at once to all computers in their network. I already worked 
on that 2 years ago but my knowledge about maintaining large Windows 
computer networks is still too limited and first tests at my university 
failed.


> Combining these two things, it's possible to create a very simple and
> portable LyX release. We could put all the binaries in a zip file and
> the user can extract this and immediately run LyX with all features.
> The only thing that needs to done manually is to run the installer for
> the LaTeX system and the Metafile to EPS Converter printer if desired.
> And there are the LaTeX classes bundled with LyX that would have to be
> copied to the MiKTeX directory.

No, only the Metafile to EPS printer installation would fail. Since 
MiKTeX 2.8 it is possible to install LaTeX-packages without admin 
permissions. Also since version 2.8, MiKTeX is fully functional when 
being installed without admin privileges.
I fully agree that we should provide a portable LyX installer. The users 
 convinced me that this is a must-have for LyX 2.0 if we would have a 
chance to spread LyX further.


> Of course the user shouldn't have to do this manually; we can also
> build a normal installer. But the point is that the installer code
> would become much more simple. We could write a script that takes the
> zip file release and converts this into a nice NSIS installer. And if
> you need to quickly edit a LyX file on somebody else's computer, the
> zip file itself is also a nice addition.

I propose to provide the portable LyX installer separately from the 
"normal" installers that write things into the registry. This would ease 
up the maintaining of the installers.


> Even the update installer that Uwe currently maintains manually could
> be automatically generated by comparing the new zip with the previous
> one and excluding unchanged files.

This would really be useful. But how can this be done? Do you plan to 
open all files in SVN's "lib" folder in text mode and compare there if a 
character was changed compared to the ones in the zip-folder of the last 
released installer? I think that only this solution will work because 
checking only the date of the files doesn't work as the SVN client 
sometimes changes the file date on my PC although the file was not changed.


> This script can be written from scratch with all the relevant people
> involved, so finally we would have a consistent way to release Windows
> binaries. This would allow any developer to generate the official
> builds and there would be only one set of official installers.

If we write it new from scratch and everyone interested is involved, I'm 
on board to use the result as official installer and will discontinue my 
installer. Only this way we would be able to overcome the current 
problem of the maintainability I mentioned in my previous post.
Currently I cannot maintain your current installer and I guess you 
cannot maintain my installer. This state is of course not acceptable in 
the long term.


We should start right now to get it ready for LyX 2.0, but I won't have 
much time for this before April 26. But if you could send your first 
version, I will comment on this as soon as possible and also promise to 
test it.


regards Uwe

Re: Importing doc documents

[Alex Fernandez]

Hi Rob,

On Mon, Mar 29, 2010 at 4:12 PM, Rob Oakes  wrote:
> LyX already imports/exports to nearly every other format under the sun
> (through the use of external tools, I know), it seems like an oversight to
> leave out the Word processor used by most people.  If you really wanted to
> get fancy, you could try and convert tracked changes and comments from the
> LyX system into MS Word, or vice-versa.  A more robust path for document
> interchange with Word users would go a *long* way to helping LyX adoption.
> I have several colleagues who would love to use it, but need a better way of
> working with MS Word users.

There is already a registered converter for MS Word. It uses HTML
formatting, which Word can import without too much trouble.
Unfortunately eLyXer (using the --html option) is not used for this
task, even though IMHO it produces better output in most cases.

Of course you are never going to get good Math with an HTML
intermediate step, but text and some formatting is readily imported
into Word. Same for OpenOffice.org Writer. This is enough for many
people. If you have any further suggestions please let me know.

Thanks,

Alex.

Re: [patch] support to set the document-wide text color

[Uwe Stöhr]

> regarding the easter eggs, have you read Joost's proposal?

Thanks for the hint. I replied now to his proposal and agreed to create 
a new installer for LyX 2.0 because this would could result in an 
installer that can be maintained by all developers - and this is the 
most important point for me.


regards Uwe

Re: LyX 2.0 / Windows - OK to start the work right now

[Joost Verburg]

On 3/30/2010 3:34 PM, Uwe Stöhr wrote:

At first, I apologize the delay in replying to this thread. I support
your ideas for a unified and new installer, see below:


Great!


If we write it new from scratch and everyone interested is involved, I'm
on board to use the result as official installer and will discontinue my
installer. Only this way we would be able to overcome the current
problem of the maintainability I mentioned in my previous post.
Currently I cannot maintain your current installer and I guess you
cannot maintain my installer. This state is of course not acceptable in
the long term.


I totally agree.


We should start right now to get it ready for LyX 2.0, but I won't have
much time for this before April 26. But if you could send your first
version, I will comment on this as soon as possible and also promise to
test it.


I haven't started working on it yet because I wanted to make sure 
everyone agrees with the approach.


I propose that for alpha 1 we build a simple zip package, since it will 
only be used by advanced users anyway. These users will already have a 
properly configured MiKTeX so they can simply extract the zip file to 
give the development version a try.


For alpha 2 the goal could be to have a basic installer, and then we can 
continue to add extra features such as automatic installation of 
hunspell dictionaries and MyThes thesaurus lists.


Joost

Re: Patch Submission: LyxBlogger Converters

[Jack Desert]

> Thanks for sending the license statement. I've added you to the credits. 

Excellent.
 
> Actually, the first issue is that, especially since 2.0 will (hopefully) 
> let the user choose conversion paths, etc, we can go ahead and install 
> both the xhtml->blog and html->blog converters. This is particularly 
> important in 2.0, it seems to me, since otherwise people who happen to 
> have had elyxer installed for use with 1.6.x would not then see that 
> they have a new option in 2.0.x.

When can we reasonably expect to see this "user chooses his own conversion 
paths" code? Which contributors are currently working on it? Is there a branch 
somewhere that at least has the GUI so we can see what it looks like?

You do have a valid point about making sure eLyXer users know there's a new kid 
on the block (LyXHTML) in 2.0. I think LyX 2.0 makes that pretty obvious with 
it's big, beautiful preview button that lists LyXHTML as one of its few 
options. Even so, the LyxBlogger xterm window already tells the user which file 
format is being used. It would be trivial yet informative to expand that 
message to: 

'''Based on your input file, you are using the eLyXer format.
LyXBlogger also supports LyX 2.0's internal LyXHTML format.
For more information, see the user's guide at ...'''

and its converse:

'''Based on your input file, you are using the LyXHTML format.
LyXBlogger also supports the eLyXer format.
For more information, see the user's guide at ...'''

 
> Or we could, except that [snip]

Or we could what? Is there a phrase missing here? 

 
> [snip]the check for elyxer does NOT guarantee that lyxblogger will only 
> see output from elyxer. This could lead to export failures and confused users.


To keep latex2html and other converters from being used, LyXBlogger could 
simply parse the html header, looking for the eLyXer style sheet, which always 
points to 
http://www.nongnu.org/elyxer/lyx.css

And  drop an error if it's not found.

'''ERROR: Unsupported Input Type 
Supported inputs are eLyXer and LyXHTML
Your input format appears to be neither of these. 
Proceed anyway? Y (N)'''

That seems quite reasonable. Easy to implement, and gives immediate feedback. 
In fact, I like it so much I'm putting it on my to do list now. 


> That makes me wonder whether lyxblogger might not operate a different 
> way, namely, as a LyX-->Blog converter that, if it is given a LyX file 
> as input, calls elyxer itself. Then we COULD do the check for elyxer 
> before registering it as a LyX-->Blog converter and all would go 
> according to plan.


Ah, but this would ideed bypass the beauty of the LyX chained converters, and 
add complexity to the front end of LyxBlogger. LyxBlogger would have to deal 
with three input types: xhtml, html, and .lyx. Which brings another question to 
mind: Can the LyX -> LyXHTML converter be called from command line? If it can, 
then both converters could theoretically be LyX -> blog. I'm not sure I'm 
interested in pursuing that route, but it's something to think about.


CONCLUSION

All said, I still support the idea of only installing one converter by default, 
as in the latest patch I provided (LyxBlogger_Formats_Patch3.diff). With the 
addition of the FORMAT messages and ERROR checking I introduced above, it keeps 
the user informed of his/her options, prevents abuse by TtH, Hevea, and others, 
and maintains elegantly uncluttered export menus. And it would be functional 
_now_, without waiting for the code from the converter-path-chooser which may 
or may not be ready for 2.0. 


-Jack


-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

Re: LyX 2.0 / Windows - OK to start the work right now

[Pavel Sanda]

Joost Verburg wrote:
>> If we write it new from scratch and everyone interested is involved, I'm
>> on board to use the result as official installer and will discontinue my
...
> I totally agree.

nice. hopefully we can survive the subsequent flames in the technical parts.
if you have some problems with the timing of releases just let me know.

pavel

Re: It's time to say goodbye

[Pavel Sanda]

Hartmut Haase wrote:
> Hi folks,
> I'm now 65 years old,

it is often surprise how different image you build in your
mind when only mail contact is possible...

i remember the double shock when the guy who could be my father
switched from the fluent german speech with Andre to slovak lang
introducing himself as Kornel ;)

> I wish the LyX project much success for the future, and may have a look into 
> it now 
> and then.

as has been already said enjoy whatsoever you plan to do now :)
of course you are welcome in the forthcoming meeting, which
will most probably take place in germany.

good luck :)
pavel

Re: Importing doc documents

[stefano franchi]

On Mon, Mar 29, 2010 at 10:12 AM, Rob Oakes  wrote:


> With that said, I had a thought.  It seems that I surrounded by happy and
> singing students that are applying for Google code fellowships and
> otherwise
> having hysterics over summer plans.  While it is too late for LyX to submit
> proposals this year, I wonder if trying to get Summer of Code students to
> work on MS Word/LyX converters might make for a good project next year?
>
>
That sounds like an excellent idea, although it's too late for this year.
Having spent the better part of a day fighting with lyx-->word conversions,
I can only dream of a bare bone converter.
I cannot be a mentor either, but i'd be more than happy to help out any way
I can (testing, etc.)

Stefano




> LyX already imports/exports to nearly every other format under the sun
> (through the use of external tools, I know), it seems like an oversight to
> leave out the Word processor used by most people.  If you really wanted to
> get fancy, you could try and convert tracked changes and comments from the
> LyX system into MS Word, or vice-versa.  A more robust path for document
> interchange with Word users would go a *long* way to helping LyX adoption.
> I have several colleagues who would love to use it, but need a better way
> of
> working with MS Word users.
>
> I'm not sure what LyX's history with Google's Summer of Code is, but if
> there is any interest, I'd be happy to help with filing applications and
> such.  I'm not sure that I'm qualified to be a mentor, but I could be a
> ruthlessly competent coordinator.
>
> Cheers,
>
> Rob Oakes
>
>


-- 
__
Stefano Franchi
Department of Philosophy   Ph:   (1) 979 862-2211
Texas A University Fax: (1) 979 845-0458
College Station, Texas, USA

Re: r33934 - in lyx-devel/trunk/src: . support tex2lyx

[rgheck]

On 03/30/2010 03:27 PM, Abdelrazak Younes wrote:

On 03/29/2010 11:31 PM, rgh...@lyx.org wrote:

Author: rgheck
Date: Mon Mar 29 23:31:17 2010
New Revision: 33934
URL: http://www.lyx.org/trac/changeset/33934

Log:
Make these const, too. I mean, why not?


Why not making the methods const too then?


They're not methods but standalone functions. ;-)

rh

Re: Importing doc documents

[stefano franchi]

On Tue, Mar 30, 2010 at 2:36 PM, Alex Fernandez wrote:

> Hi Rob,
>
> There is already a registered converter for MS Word. It uses HTML
> formatting, which Word can import without too much trouble.
> Unfortunately eLyXer (using the --html option) is not used for this
> task, even though IMHO it produces better output in most cases.
>
> In my, very recent, experience, there are several converters Lyx->Word, but
no *robust* one.
Problems I encountered yesterday trying to convert a relatively simple
15-pages lyx  file that compiled perfectly to pdf into word:

-- all character sequences including ligatures (ff, ffi, etc) disappearing,
silently, from the output

--- all accented characters being converted into the wrong glyphs

--- tables mangled beyond recognition, or simply (again, silently)
suppressed from the output

--- images missing, or distorted, or resized to full page, etcetera

-- many other problems that I now (happily) forget


I tried everything I could find: the lyx html(word) export, html export, and
oolatex (all variations of htlatex, I seem to remember), hevea, tth,
latex2rtf, elixer
I eventually managed to produce something barely acceptable, but it was a
nightmare.


S.







> Of course you are never going to get good Math with an HTML
> intermediate step, but text and some formatting is readily imported
> into Word. Same for OpenOffice.org Writer. This is enough for many
> people. If you have any further suggestions please let me know.
>
> Thanks,
>
> Alex.
>



-- 
__
Stefano Franchi
Department of Philosophy   Ph:   (1) 979 862-2211
Texas A University Fax: (1) 979 845-0458
College Station, Texas, USA

Re: Patch Submission: LyxBlogger Converters

[rgheck]

On 03/30/2010 04:15 PM, Jack Desert wrote:



Actually, the first issue is that, especially since 2.0 will (hopefully)
let the user choose conversion paths, etc, we can go ahead and install
both the xhtml->blog and html->blog converters. This is particularly
important in 2.0, it seems to me, since otherwise people who happen to
have had elyxer installed for use with 1.6.x would not then see that
they have a new option in 2.0.x.
 

When can we reasonably expect to see this "user chooses his own conversion 
paths" code? Which contributors are currently working on it? Is there a branch 
somewhere that at least has the GUI so we can see what it looks like?

   
Jurgen did a bunch of work on it but ran into a problem. I've told him 
I'll help him sort it out and did some of the necessary background work. 
But then he got busy and otherwise distracted, so it's kind of on hold 
for the moment. But I think we both really want to get it into 2.0. If 
not, then it would almost certainly have to wait for 2.0, due to file 
format issues.



Or we could, except that [snip]
 

Or we could what? Is there a phrase missing here?

   
I think I meant: We could install lyxblogger as an html->blog converter, 
but...


   

[snip]the check for elyxer does NOT guarantee that lyxblogger will only
see output from elyxer. This could lead to export failures and confused users.
 


To keep latex2html and other converters from being used, LyXBlogger could 
simply parse the html header, looking for the eLyXer style sheet, which always 
points to
 http://www.nongnu.org/elyxer/lyx.css

And  drop an error if it's not found.

 '''ERROR: Unsupported Input Type
 Supported inputs are eLyXer and LyXHTML
 Your input format appears to be neither of these.
 Proceed anyway? Y (N)'''

That seems quite reasonable. Easy to implement, and gives immediate feedback. 
In fact, I like it so much I'm putting it on my to do list now.

   
This is all true, though note that, from within LyX itself, you can't 
ask the question "Proceed anyway?" There's no mechanism for LyX to 
communicate with the running script. Indeed, if you tried to ask such a 
question, the script would freeze, waiting for input. So you either 
proceed or you don't.


I do not mean any of this as a criticism of lyxblogger. My point is just 
that the way LyX's whole converter mechanism is designed presently makes 
integrating it somewhat messy. Each converter defines a path in a graph, 
and the question "what conversions are possible?" then becomes the 
question: Is there a path from format A to format B? You can get some 
pretty wild conversion paths sometimes---there are actually some weird 
issues that result from elyxer's being a LyX-->HTML converter---but it 
is a very flexible system. My ponit is that depends upon converters 
being able to convert between the formats that they advertise as being 
able to convert between. So, to totally overstate the point, from LyX's 
point of view what this means is that lyxblogger isn't really an html to 
blog converter. It doesn't even purport to work with arbitrary HTML 
files. So installing it as an html to blog converter means installing an 
html to blog converter that we know won't work if someone chooses to 
override the choice of elyxer and instead to go lyx->latex->html.


Right now, that isn't possible, so the sort of patch you provided would 
work perfectly fine in 1.6.6. I'd suggest you prepare a patch, doing 
just the elyxer part, for branch, post it, and see if we get approval 
from Jurgen. For 2.0, it would also work as things presently are. But 
trunk isn't really usable right now, except by the very brave or very 
stupid, so there's no rush. I'd propose that we wait on this for the 
time being and see what happens with the "choose your converter" stuff. 
Once we get near beta, we will do something.



That makes me wonder whether lyxblogger might not operate a different
way, namely, as a LyX-->Blog converter that, if it is given a LyX file
as input, calls elyxer itself. Then we COULD do the check for elyxer
before registering it as a LyX-->Blog converter and all would go
according to plan.
 


Ah, but this would ideed bypass the beauty of the LyX chained converters,

   
Yes, I know, but maybe the previous explanation makes the point of the 
suggestion clearer.



and add complexity to the front end of LyxBlogger. LyxBlogger would have to 
deal with three input types: xhtml, html, and .lyx.

   

Not pretty, I know.


Which brings another question to mind: Can the LyX ->  LyXHTML converter be 
called from command line?

   

Yes, this is possible: lyx -e xhtml file.lyx.


If it can, then both converters could theoretically be LyX ->  blog. I'm not 
sure I'm interested in pursuing that route, but it's something to think about.

   
Worth thinking about, yes. Not clear how much benefit there is there, 
but maybe some.


rh

Re: I can´t run lyx 2.0.0 alpha 1

[Marcelo Acuña]

> >>> I have download alpha 1,
> >> configure, compile and install without problem.
> >>> But when I run it get:
> >>>
> >>> lyx-2.0.0.a1: symbol lookup error:
> lyx-2.0.0.a1:
> >> undefined
> >>> symbol: _ZN11QVectorData4freeEPS_i
> >>>
> >>> I have debian lenny with g++ 4.3.2, qt 4.6.2.
> >>>
> >>> Regards
> >> Usually, you use a different run-time version of
> Qt as the
> >> one you used in the compilation.
> >>
> >> Vincent
> > 
> Have you done a system update after building LyX?
> Then you've linked against a Qt version which is not
> available any more on your system after your update.
> 
> Peter

 Problem solved.
 I make an update before build Lyx, but something no work well and libs from 
previous version still remained.
 I corrected the problem and now all work ok.
 Thanks!
Marcelo


  Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.


http://ar.mujer.yahoo.com/cocina/

Re: [patch] fix #3865 - support to change the font color for greyed-out notes

[Uwe Stöhr]

I wrote:


Attached is a patch for
http://www.lyx.org/trac/ticket/3865
This would of course be a fileformat change.


An improved version of the patch is in.

There is one remaining problem: When opening a file where the font color is set as in the attached 
file. The color is not displayed in LyX. The strange thing is that the font is correctly displayed 
in the document font settings dialog.


The problem is that
lcolor.setColor()
in BufferParams::readToken()
is ignored.
This bug turns out to be a general one that is also present in LyX 1.6.6svn:
http://www.lyx.org/trac/ticket/6626

regards Uwe


ColorTest3.lyx
Description: application/lyx

Re: Importing doc documents

[Alex Fernandez]

Hi Stefano,

On Tue, Mar 30, 2010 at 10:18 PM, stefano franchi
 wrote:
> In my, very recent, experience, there are several converters Lyx->Word, but
> no *robust* one.
> Problems I encountered yesterday trying to convert a relatively simple
> 15-pages lyx  file that compiled perfectly to pdf into word:

Please send your document to me, or to the eLyXer user list. You can
lorem-ipsumize it (using the loremipsumize.py script included with
eLyXer) if needed. I will do my best to make eLyXer output acceptable
HTML code.

> I tried everything I could find: the lyx html(word) export, html export, and
> oolatex (all variations of htlatex, I seem to remember), hevea, tth,
> latex2rtf, elixer
> I eventually managed to produce something barely acceptable, but it was a
> nightmare.

Did you get better results with eLyXer, or was it just the same as the
others? Just curious.

Alex.

new regression bug in LyX 2.0svn

[Uwe Stöhr]

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

regards Uwe

[patch] support for Turkmen

[Uwe Stöhr]

The attached patch adds support for Turkmen
(http://en.wikipedia.org/wiki/Turkmen_language)
This will be a fileformat change.

regards Uwe
Index: development/FORMAT
===
--- development/FORMAT	(revision 33963)
+++ development/FORMAT	(working copy)
@@ -2,6 +2,9 @@
 ---
 
 2010-03-31 Uwe Stöhr 
+	* Format incremented to 383: support for Turkmen
+
+2010-03-31 Uwe Stöhr 
 	* Format incremented to 382: support to change the font color
 	for greyed-out notes
 
Index: lib/languages
===
--- lib/languages	(revision 33963)
+++ lib/languages	(working copy)
@@ -82,6 +82,7 @@
 swedish swedish	"Swedish"	false  iso8859-15 sv_SE	 ""
 thaithai	"Thai"		false  tis620-0   th_TH	 "\usepackage{thswitch}"
 turkish turkish	"Turkish"	false  iso8859-9  tr_TR	 ""
+turkmen turkmen	"Turkmen"	false  utf8   tk_TM	 ""
 ukrainian   ukrainian	"Ukrainian"	false  koi8-u uk_UA	 ""
 uppersorbianuppersorbian	"Upper Sorbian"	false  iso8859-2  hsb_DE	 ""
 vietnamese  vietnam	"Vietnamese"	false  utf8   vi_VN	 ""
Index: lib/lyx2lyx/lyx_2_0.py
===
--- lib/lyx2lyx/lyx_2_0.py	(revision 33963)
+++ lib/lyx2lyx/lyx_2_0.py	(working copy)
@@ -1376,6 +1376,23 @@
+ ' {\\textcolor{note_fontcolor}\\bgroup}{\\egroup}\n')
 
 
+def revert_turkmen(document):
+"Set language Turkmen to English" 
+i = 0 
+if document.language == "turkmen": 
+document.language = "english" 
+i = find_token(document.header, "\\language", 0) 
+if i != -1: 
+document.header[i] = "\\language english" 
+j = 0 
+while True: 
+j = find_token(document.body, "\\lang turkmen", j) 
+if j == -1: 
+return 
+document.body[j] = document.body[j].replace("\\lang turkmen", "\\lang english") 
+j = j + 1 
+
+
 ##
 # Conversion hub
 #
@@ -1417,10 +1434,12 @@
[379, [convert_math_output]],
[380, []],
[381, []],
-   [382, []]
+   [382, []],
+   [383, []]
   ]
 
-revert =  [[381, [revert_notefontcolor]],
+revert =  [[382, [revert_turkmen]],
+   [381, [revert_notefontcolor]],
[380, [revert_equalspacing_xymatrix]],
[379, [revert_inset_preview]],
[378, [revert_math_output]],
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 33963)
+++ src/Buffer.cpp	(working copy)
@@ -126,7 +126,7 @@
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 382; // uwestoehr: support to change font color for greyed-out notes
+int const LYX_FORMAT = 383; // uwestoehr: support for Turkmen
 
 typedef map DepClean;
 typedef map RefCache;
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 33963)
+++ src/BufferParams.cpp	(working copy)
@@ -1210,10 +1210,12 @@
 		// viet = string::npos when not found
 		// the same is for all other languages that are not directly supported by
 		// babel, but where LaTeX-packages add babel support.
-		// this is currently the case for Latvian, Lithuanian, and Mongolian
+		// this is currently the case for Latvian, Lithuanian, Mongolian
+		// and Turkmen
 		size_t latvian = language_options.str().find("latvian");
 		size_t lithu = language_options.str().find("lithuanian");
 		size_t mongo = language_options.str().find("mongolian");
+		size_t turkmen = language_options.str().find("turkmen");
 		// if Japanese is used, babel must directly be loaded
 		// with language options, not in the class options, see
 		// http://www.lyx.org/trac/ticket/4597#c4
@@ -1221,7 +1223,7 @@
 		if (lyxrc.language_global_options && !language_options.str().empty()
 			&& viet == string::npos && japan == string::npos
 			&& latvian == string::npos && lithu == string::npos
-			&& mongo == string::npos)
+			&& mongo == string::npos && turkmen == string::npos)
 			clsoptions << language_options.str() << ',';
 	}
 
@@ -2103,17 +2105,20 @@
 	// viet = string::npos when not found
 	// the same is for all other languages that are not directly supported by
 	// babel, but where LaTeX-packages add babel support.
-	// this is currently the case for Latvian, Lithuanian, and Mongolian
+	// this is currently the case for Latvian, Lithuanian, Mongolian
+	// and Turkmen
 	size_t latvian = lang_opts.find("latvian");
 	size_t lithu = lang_opts.find("lithuanian");
 	size_t mongo = lang_opts.find("mongolian");
+	size_t turkmen = lang_opts.find("turkmen");
 	// If Japanese is used, babel must directly be loaded with the
 	// language options, see
 	// 

Re: new regression bug in LyX 2.0svn

[Julien Rioux]

On 30/03/2010 9:22 PM, Uwe Stöhr wrote:

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

regards Uwe



Isn't this the same as http://www.lyx.org/trac/ticket/6519 ?

--
Julien

revtex 4-1 layout password

[Anton Starikov]

Hi,

I would like to test new revtex4-1 layout, can I get password for it?

Thank you, 

Anton Starikov

[patch] Dot -> Image formats

[Julien Rioux]

Hi List,

I was pleasantly surprised today when I realised I could directly input 
a .dot graph file into LyX and LyX would do the conversion 
automatically. No need to set up converters!


However the quality of the postscript output was poor. So I went and 
checked: there was no dot->eps converter, only a dot->pdf one.


LyX knows of a chain to convert pdf->eps, but along the way quality was 
lost somehow. Therefore I suggest the following patch, using the dot 
utility to perform all dot->(something else) conversions. For my setup, 
the output definitely has better quality in this way.


Regards,
Julien
Index: lib/configure.py
===
--- lib/configure.py(revision 33961)
+++ lib/configure.py(working copy)
@@ -757,8 +757,13 @@
 \converter agrppm"gracebat -hardcopy -printfile $$o -hdevice 
PNM $$i 2>/dev/null"  ""''',
 ''])
 #
-checkProg('a Dot -> PDF converter', ['dot -Tpdf $$i -o $$o'],
-rc_entry = [ r'\converter dotpdf"%%"   ""'])
+checkProg('a Dot -> Image converter', ['dot'],
+rc_entry = [
+r'''\converter doteps"dot -Teps $$i -o $$o"
""
+\converter dotjpg"dot -Tjpg $$i -o $$o"""
+\converter dotpdf"dot -Tpdf $$i -o $$o"""
+\converter dotpng"dot -Tpng $$i -o $$o"""''',
+''])
 #
 checkProg('a Dia -> PNG converter', ['dia -e $$o -t png $$i'],
 rc_entry = [ r'\converter diapng"%%"   ""'])