Re: How to resolve relyx bugs?
Georg Baum <[EMAIL PROTECTED]> writes: | What shall I do with relyx bugs that are fixed in tex2lyx (e.g. | http://bugzilla.lyx.org/show_bug.cgi?id=1620 )? FIXED (because it works in | tex2lyx) or WONTFIX (because it will not be fixed in relyx)? I have used WONTFIX, but of course if the same but is in tex2lyx the bug should be transfered there with a note. -- Lgb
Re: [PATCH] DocBook cleanID and math
Georg Baum <[EMAIL PROTECTED]> writes: | Andreas Vox wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: >> >>> Here I'm using the knode news reader and have no such problems. > | Me too. > >> AppleMail doesn't do news and I'm not accustomed to ThunderBird yet. > | I am sure that decent news readers exist for macs, too. There is Gnus. Mail reader, news reader. -- Lgb
Re: Patch - DTD - And lyx file
On Thu, Oct 14, 2004 at 12:22:41AM +0100, José Abílio Oliveira Matos wrote: > On Thu, Oct 14, 2004 at 12:42:45AM +0200, Lars Gullik Bjønnes wrote: > > > > > > > > I doubt, we don't want to bind the lyx dtd with the different textclasses, > that is the advantage of extensibility. I say define anything that depends on environment ... like the textclasses ... as simple string attributes. We can make exceptions for *certain* textclasses ... like "Standard" ... that are pretty much universal. Just my $0.02 worth. -- John Weiss
Re: Patch - DTD - And lyx file
On Sun, Oct 17, 2004 at 11:41:55AM +0200, Lars Gullik Bjønnes wrote: > > To make the lists be lists in the xml doc will be quite hard (or so I > belive), it would be nice, but with no help from the internal > structure it will IMHO be very errorprone, so I have postphoned that > transformation for now. I feel that the structural loading/saving hints can be supplied via attributes on the items or the surrounding list-defn.-tags. Got hit with a bad cold, then had interviews all this week. I'll look at the new DTD on the train tomorrow and try to come up with suggestions. -- John Weiss
Re: [PATCH] DocBook cleanID and math
On Thu, Oct 21, 2004 at 10:21:56AM +0200, Andreas Vox wrote: > Hi! > > I submit my patch from last weekend again with bug fixes and split into > parts. I know that this is the second time I ask you to do this, but could you redo your patch against current cvs? This is what I get when trying to apply the patch: $ patch -u -p0 --dry-run < /home/jamatos/patch-db-ids+math.txt patching file src/paragraph.C patching file src/sgml.C patch: malformed patch at line 46: namespace sgml { > This one is the biggest, it contains the changes to math_hullinset and > the new > 'cleanID' function. > > Content: > > * calling 'sgml::cleanID' when outputting SGML or XML ids or linkends. > * changing the namemangling in 'cleanID' to be unique and according to > SGML decl. This is I don't understand. XML has a less restrictive model, yet the patch seems to apply the same function no matter what. Or am I understanding it wrong? > * mathed: escaping '&' and '<' in output > * element for equations > > Oh yes, and I made a :%s/ // in vi, so there shouldn't be any > superflous spaces left ;-) > > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook graphic -> mediaobject
On Thu, Oct 21, 2004 at 10:24:17AM +, Andreas Vox wrote: > Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > > Andreas Vox <[EMAIL PROTECTED]> writes: > > | - case LyXLength::PT: //< Point = 1/72.27in = 0.351mm > > | + case LyXLength::PT: // Point = 1/72.27in = 0.351mm > > | result << len.value() * 72 / 72.27 << "pt"; > > > > The '<' is there for a reason. > > Yes. The reason is I copy&pasted this comments from their declaration :-) > > > Don't remove them. (rather fix them to be '///<') > > Doxygen'ing case labels seems rather radical to me ;-) Did you fix it after? The patch that you sent me is applied, I verified several details, but not this. :-) > Cheers > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH} Docbook citation
On Thu, Oct 21, 2004 at 10:23:29AM +0200, Andreas Vox wrote: > Hi! > > This is a small and independent patch which was already discussed. > > /Andreas Applied. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Changelogs for the other Docbook patches
On Thu, Oct 21, 2004 at 10:38:56AM +0200, Andreas Vox wrote: > Hi! > > I bundled those extra since they relate to all other patches. > This time I didn't erase any blanks but replaced all blanks > by double blanks, as is required for the Changelog format ;-) Aha, not quite. :-) But nevermind I will fix that. > Josè, could you commit these patches? I want to go on with > the allowedNameChars runparam, DBTeXMath, calling > 'escapeEntities' where needed and further debugging. > It just feels wrong when my version gets far off the CVS version > and my patches get larger and more interconnected. First, I appreciatte that you an accent in my name. But you got the wrong one, è doesn't exists in portuguese. While it appears that ã only exists in portuguese and õ in portuguese an lituanian. And why do I know all those details? Because I have been reading the unicode website because of you know what. :-) If you don't mind I take care of the allowed names. I want to have also some fun. ;-) > /Andreas > Index: src/output_docbook.C > === > RCS file: /cvs/lyx/lyx-devel/src/output_docbook.C,v > retrieving revision 1.11 > diff -u -p -r1.11 output_docbook.C > --- src/output_docbook.C 2004/10/13 22:15:32 1.11 > +++ src/output_docbook.C 2004/10/21 07:35:02 > @@ -95,7 +95,7 @@ void docbookParagraphs(Buffer const & bu > > string ls = par->getDocbookId(); > if (!ls.empty()) > - ls = " id = \"" + ls + "\""; > + ls = " id=\"" + ls + "\""; > > // Write opening SGML tags. > switch (style->latextype) { You speak of changelogs and send me a code change? ;-) > Index: src/insets/ChangeLog > === > RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v > retrieving revision 1.1050 > diff -u -p -r1.1050 ChangeLog > --- src/insets/ChangeLog 2004/10/05 13:38:30 1.1050 > +++ src/insets/ChangeLog 2004/10/21 07:35:12 > @@ -1,3 +1,12 @@ > +2004-17-05 Andreas Vox <[EMAIL PROTECTED]> ??? XML is a ISO standard, but not for dates. ;-) > + > + * insetref.C (docbook): clean illegal chars in ID > + * insetlabel.C (docbook): clean illegal chars in ID > +* insetgraphics.C (docbook, writeImageObject): write more than See here, 8 spaces. > + one format of imageobjects in > +* insetcite.[hC] (docbook, latex, cleanupWhitespace): > implementing As here. > +DocBook output for this inset ( content ) > + > 2004-10-05 Andreas Vox <[EMAIL PROTECTED]> > > * insetgraphics.C (docbook) : using mediaobject for XML; -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH} Docbook citation
On Thu, Oct 21, 2004 at 10:23:29AM +0200, Andreas Vox wrote: > Hi! > > This is a small and independent patch which was already discussed. Applied. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Moving files from one dir to another
Angus Leeming <[EMAIL PROTECTED]> writes: > It looks like I opened a can of worms with this XFig stuff > I caught up with my reading (previous DVI file thread on lyx-devel, insetexternal, etc.) and I don't envy you :-) ... > Usually, Mover will just invoke '::rename', or 'mv' when a shell script > representation is requested for the graphics converter. However, this will > be configurable, based on file format. Users can register an external > command to do something more complex. So it's something like a converter with source format == target format? Or do converters have a restriction of working only in one directory? For my taste this whole external file business is already very complicated. A Mover would be a clean solution but also another concept to learn. (my head is already spinning from converters, templates, previewloaders, graphicloaders, etc.) About your code: how do you decide when to copy and when to move? Shouldn't there be some parameter in the interfaces? Cheers /Andreas
Moving files from one dir to another
It looks like I opened a can of worms with this XFig stuff :-( Trivial as it may seem, it just isn't that easy to define and use a $$orig_i placeholder. Lots of messy and fragile changes all over the place. However, it seems to me that the problems can be isolated to the concept of 'moving a file from one place to another'. I think that we need a class to reflect this concept. Usually, Mover will just invoke '::rename', or 'mv' when a shell script representation is requested for the graphics converter. However, this will be configurable, based on file format. Users can register an external command to do something more complex. For example: \mover "fig" "sh $$s/move_fig.sh $$i $$o" See attached files mover.[Ch]. The advantage, of course, is that the approach is extendable to arbitrary formats. Tgif and Dia spring to mind. Does this seem like the right way to go? -- Angus/** * \file mover.C * This file is part of LyX, the document processor. * Licence details can be found in the file COPYING. * * \author Angus Leeming * * Full author contact details are available in file CREDITS. */ #include "mover.h" #include "format.h" #include "support/filetools.h" #include "support/lstrings.h" #include "support/lyxlib.h" #include "support/systemcall.h" #include using std::ostringstream; using std::string; namespace support = lyx::support; bool Mover::move(string const & from, string const & to) const { return support::rename(from, to); } string const Mover::sh_move(string const & from, string const & to) const { ostringstream out; out << "fromfile=" << from << "\n" << "tofile=" << to << "\n\n" << "'mv' -f \"${fromfile}\" \"${tofile}\" ||\n" << "{\n" << "\t'cp' -f \"${fromfile}\" \"${tofile}\" ||\n" << "\t{\n" << "\t\texit 1\n" << "\t}\n" << "\t'rm' -f \"${fromfile}\"\n" << "}\n"; return out.str(); } SpecialisedMover::SpecialisedMover(string const & command) : command_(support::LibScriptSearch(command)) {} bool SpecialisedMover::move(string const & from, string const & to) const { string command = support::subst(command_, "$$i", from); command = support::subst(command, "$$o", to); support::Systemcall one; return one.startscript(support::Systemcall::Wait, command); } string const SpecialisedMover::sh_move(string const & from, string const & to) const { string command = support::subst(command_, "$$i", "\"${fromfile}\""); command = support::subst(command, "$$o", "\"${tofile}\""); return command + " || exit 1\n"; } Movers & Movers::get() { static Movers singleton; return singleton; } void Movers::set(Format const & fmt, string const & command) { typedef boost::shared_ptr SpecialisedMoverPtr; specials_[fmt.name()] = SpecialisedMoverPtr(new SpecialisedMover(command)); } Mover const & Movers::operator()(Format const & fmt) const { SpecialsMap::const_iterator it = specials_.find(fmt.name()); return (it == specials_.end()) ? default_ : *it->second; } // -*- C++ -*- /** * \file mover.h * This file is part of LyX, the document processor. * Licence details can be found in the file COPYING. * * \author Angus Leeming * * Full author contact details are available in file CREDITS. */ #ifndef MOVER_H #define MOVER_H #include #include #include #include class Format; /** * Utility to move a file of a specified format from one directory to * another or to output a snippet of sh-script that will perform the * move. * * This base class simply invokes the system command ::rename() or * outputs a sh-code snippet that uses 'mv' and 'cp'. */ class Mover { public: virtual ~Mover() {} /** Move file @c from to @c to. * @returns true if successful. */ bool operator()(std::string const & from, std::string const & to) const { return move(from, to); } /** @returns a set of shell script commands to move file * @c from to @c to. */ std::string const sh_command(std::string const & from, std::string const & to) const { return sh_move(from, to); } private: virtual bool move(std::string const & from, std::string const & to) const; virtual std::string const sh_move(std::string const & from, std::string const & to) const; }; /** * Specialization of the Mover concept that uses an external command * to perform the movement of a file. * * For example, an XFig .fig file can contain references to external * picture files. If such a reference has a relative path, then moving * the .fig file will require a transformation of the picture file * reference if it is to be found by XFig. */ struct SpecialisedMover : public Mover { /** @c command should be of the form * * sh $$s/move_fig.sh $$i $$o * * where $$s is a placeholder for the lyx script directory, *$$i is a placeholder for the name of the file to be moved, *$$o is a placeholder for the name of the file after moving. */ SpecialisedMover(std::string const & command); private: virtual b
Re: CVS lyx: make rpmdist failing
On Thu, Oct 21, 2004 at 08:47:22PM +0200, Georg Baum wrote: > Am Donnerstag, 21. Oktober 2004 19:46 schrieb Kayvan A. Sylvan: > > Did something change recently with the RPM spec file or the build > process? > > Yes. I made rpms with version suffix work (at on my machine). > > > + ./configure --with-frontend=xforms --prefix=/usr > --mandir=/usr/share/man --bin > > dir=/usr/bin --datadir=/usr/share --without-warnings --disable-debug > --enable-op > > timization=-O2 %{version_suffix} > > Why is that %{version_suffix}? This should be an empty variable or a > string like "--with-version-suffix=1.4" Have you tried it with an empty body? My RPM complains about the empty body and it never gets substituted. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: A real prblem with XFig images
Am Donnerstag, 21. Oktober 2004 20:38 schrieb Angus Leeming: > Georg Baum wrote: > > > Angus Leeming wrote: > > > >> Georg Baum wrote: > >> > >>> No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and > >>> 'images/img.eps.' This is alo a case where the converter is called on > >>> the original file and therefore modifies it :-((( > >> > >> Not so. It modifies a COPY of the original file. That's a big > >> difference. > > > > Not for latex export. For dvi, ps, pdf export, yes. The reason was > > probably that we don't want the mangled file names in the .tex file. > > > >> Ok, so the bottom line is that a call to > >> Export->Latex > >> results in everything that would be needed to compile buffer.tex being > >> placed in the /tmp/lyx_tmp.../lyx_tmpbuf0/ directory? The only > >> conceptual > > > > No. The original files are converted where they are, but we should > > convert copies in the tmp directory. > > You mean that if buffer.lyx has a graphics inset referencing foo.eps, then > generating the DVI file does not result in a copy of foo.eps being placed > in the temp directory? I'll take your word for it, but a single directory > containing all necessary files would be neater somehow, no? No, not for DVI files. Today seems to be the day of misunderstandings ;-( In addition, I have rechecked, and it turns out that what I wrote applies only to the external inset, not to the graphics inset. The graphics inset does all conversions in the temp dir, on copies of the original files, as it should be. The external inset is different. For latex export (read: runparams.nice == true), it does do the conversions directly on the original file. For all other formats it does the conversions in the temp dir. I tried to change the external inset: Do all conversions in the temp dir, and copy the results back afterwards. But then we have the problem that the .pstex_t file contains \includegraphics{}, because fig2pstex.sh sees only the temp file. I currently don't know how to change that without being too smart. > >>> Another problem is that fig2pstex.sh does not know of latex's stupid > >>> interpretation of relative filenames (relative to the master document, > >>> not the included one. Therefore images/img.pstex_t contains > >>> \includegraphics{img}, and this fails of course. > >> > >> Ok, I understand your point. I don't think that it's right because my > >> 'nasty' hack changes that to \includegraphics{/img}, > >> no? > > > > ??? > > It replaces the filename in the .fig file, not the filename in the > > .pstex_t file. The latter is wrong, the .fig file is ok. Now I get > > confused ;-) > > But the .pstex_t file is generated from the .fig file. I'd investigate > further, but Jean-Marc's quotes are biting me. It is generated from the .fig file, but your hack does not change its name (at least it did not when I tried it). I hope this time I am not confusing! A related question: It seems that the entries in lib/external-templates for xfig are wrong. I think they should be modified (see attachment), since fig2pstex.sh creates an .eps file and no .pstex file, fig2pdftex.sh is similar. Please confirm wether this is correct or not. Georg --- lyx-1.4-clean/lib/external_templates 2004-06-01 15:32:22.0 +0200 +++ lyx-1.4-cvs/lib/external_templates 2004-10-21 21:01:43.0 +0200 @@ -122,8 +122,8 @@ # Preamble WarnNotFound # Preamble InputOrWarn ReferencedFile latex "$$AbsPath$$Basename.pstex_t" - ReferencedFile latex "$$AbsPath$$Basename.pstex" - ReferencedFile dvi "$$AbsPath$$Basename.pstex" + ReferencedFile latex "$$AbsPath$$Basename.eps" + ReferencedFile dvi "$$AbsPath$$Basename.eps" FormatEnd Format PDFLaTeX TransformCommand Rotate RotationLatexCommand @@ -135,7 +135,7 @@ # Preamble WarnNotFound # Preamble InputOrWarn ReferencedFile latex "$$AbsPath$$Basename.pdftex_t" - ReferencedFile latex "$$AbsPath$$Basename.pdftex" + ReferencedFile latex "$$AbsPath$$Basename.pdf" FormatEnd Format Ascii Product "$$Contents(\"$$AbsPath$$Basename.asc\")"
Re: CVS lyx: make rpmdist failing
Am Donnerstag, 21. Oktober 2004 19:46 schrieb Kayvan A. Sylvan: > Did something change recently with the RPM spec file or the build process? Yes. I made rpms with version suffix work (at on my machine). > + ./configure --with-frontend=xforms --prefix=/usr --mandir=/usr/share/man --bin > dir=/usr/bin --datadir=/usr/share --without-warnings --disable-debug --enable-op > timization=-O2 %{version_suffix} Why is that %{version_suffix}? This should be an empty variable or a string like "--with-version-suffix=1.4" It is set in the second line of the spec file. How does it look like? Georg
Re: A real prblem with XFig images
Georg Baum wrote: > Angus Leeming wrote: > >> Georg Baum wrote: >> >>> Angus Leeming wrote: 2. Export->Latex buffer.tex will include the snippet: \input{images/img.pstex_t} It is the user's responsibility to generate 'images/img.pstex_t' correctly. >>> >>> No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and >>> 'images/img.eps.' This is alo a case where the converter is called on >>> the original file and therefore modifies it :-((( >> >> Not so. It modifies a COPY of the original file. That's a big >> difference. > > Not for latex export. For dvi, ps, pdf export, yes. The reason was > probably that we don't want the mangled file names in the .tex file. > >> Ok, so the bottom line is that a call to >> Export->Latex >> results in everything that would be needed to compile buffer.tex being >> placed in the /tmp/lyx_tmp.../lyx_tmpbuf0/ directory? The only >> conceptual > > No. The original files are converted where they are, but we should > convert copies in the tmp directory. You mean that if buffer.lyx has a graphics inset referencing foo.eps, then generating the DVI file does not result in a copy of foo.eps being placed in the temp directory? I'll take your word for it, but a single directory containing all necessary files would be neater somehow, no? >>> Another problem is that fig2pstex.sh does not know of latex's stupid >>> interpretation of relative filenames (relative to the master document, >>> not the included one. Therefore images/img.pstex_t contains >>> \includegraphics{img}, and this fails of course. >> >> Ok, I understand your point. I don't think that it's right because my >> 'nasty' hack changes that to \includegraphics{/img}, >> no? > > ??? > It replaces the filename in the .fig file, not the filename in the > .pstex_t file. The latter is wrong, the .fig file is ok. Now I get > confused ;-) But the .pstex_t file is generated from the .fig file. I'd investigate further, but Jean-Marc's quotes are biting me. -- Angus
CVS lyx: make rpmdist failing
Did something change recently with the RPM spec file or the build process? + ./configure --with-frontend=xforms --prefix=/usr --mandir=/usr/share/man --bin dir=/usr/bin --datadir=/usr/share --without-warnings --disable-debug --enable-op timization=-O2 %{version_suffix} configure: WARNING: you should use --build, --host, --target configure: WARNING: invalid host type: %{version_suffix} configuring LyX version 1.4.0cvs WARNING: This is a development version. Expect bugs. checking whether to enable maintainer-specific portions of Makefiles... yes checking build system type... Invalid configuration `%{version_suffix}': machine `%{version_suffix}' not recognized configure: error: /bin/sh config/config.sub %{version_suffix} failed -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: [patch] bug 1523 (LyX 1.3.x)
Jean-Marc Lasgouttes wrote: > Fixing this bug would be a very good idea indeed. What the reason why > you choose this way instead of replicating 1.4.0 code? Do you think > it is safer? No. I just looked for a solution that does not require to rewrite the whole function. Anyway, attached is the 1.4cvs-solution, backported to 1.3.x OK to apply? Jürgen Index: src/lyxlength.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlength.C,v retrieving revision 1.26 diff -u -r1.26 lyxlength.C --- src/lyxlength.C 4 Dec 2002 02:57:14 - 1.26 +++ src/lyxlength.C 21 Oct 2004 17:04:35 - @@ -59,37 +59,33 @@ string const LyXLength::asLatexString() const { - ostringstream buffer; + char buffer[80]; switch (unit_) { case PTW: - buffer << abs(static_cast(val_/100)) << '.' - << abs(static_cast(val_)%100) << "\\textwidth"; - break; + snprintf(buffer, 78, "%.2f\\textwidth", val_/100.0); + break; case PCW: - buffer << abs(static_cast(val_/100)) << '.' - << abs(static_cast(val_)%100) << "\\columnwidth"; - break; + snprintf(buffer, 78, "%.2f\\columnwidth", val_/100.0); + break; case PPW: - buffer << abs(static_cast(val_/100)) << '.' - << abs(static_cast(val_)%100) << "\\paperwidth"; - break; + snprintf(buffer, 78, "%.2f\\paperwidth", val_/100.0); + break; case PLW: - buffer << abs(static_cast(val_/100)) << '.' - << abs(static_cast(val_)%100) << "\\linewidth"; - break; + snprintf(buffer, 78, "%.2f\\linewidth", val_/100.0); + break; case PPH: - buffer << abs(static_cast(val_/100)) << '.' - << abs(static_cast(val_)%100) << "\\paperheight"; - break; + snprintf(buffer, 78, "%.2f\\paperheight", val_/100.0); + break; case PTH: - buffer << abs(static_cast(val_/100)) << '.' - << abs(static_cast(val_)%100) << "\\textheight"; - break; + snprintf(buffer, 78, "%.2f\\textheight", val_/100.0); + break; default: - buffer << val_ << unit_name[unit_]; // setw? - break; + snprintf(buffer, 78, "%f%s", val_, unit_name[unit_]); + break; } - return STRCONV(buffer.str()); + // paranoia + buffer[79] = 0; + return buffer; }
Re: A real prblem with XFig images
Angus Leeming wrote: > Georg Baum wrote: > >> Angus Leeming wrote: >>> 2. Export->Latex >>> buffer.tex will include the snippet: >>> \input{images/img.pstex_t} >>> It is the user's responsibility to generate 'images/img.pstex_t' >>> correctly. >> >> No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and >> 'images/img.eps.' This is alo a case where the converter is called on the >> original file and therefore modifies it :-((( > > Not so. It modifies a COPY of the original file. That's a big difference. Not for latex export. For dvi, ps, pdf export, yes. The reason was probably that we don't want the mangled file names in the .tex file. > Ok, so the bottom line is that a call to > Export->Latex > results in everything that would be needed to compile buffer.tex being > placed in the /tmp/lyx_tmp.../lyx_tmpbuf0/ directory? The only conceptual No. The original files are converted where they are, but we should convert copies in the tmp directory. > problem thereafter is working out which of these files to 'return' in a > 'buffer_latex' directory. (This is something we don't do but maybe should > consider doing in the future?) This is no problem, we have ExportData::externalFiles() for this purpose. Right now, I don't understand anymore why we don't convert the files in the temp dir and then copy them to the buffer dir, because all the needed machinery is there. >> Another problem is that fig2pstex.sh does not know of latex's stupid >> interpretation of relative filenames (relative to the master document, >> not the included one. Therefore images/img.pstex_t contains >> \includegraphics{img}, and this fails of course. > > Ok, I understand your point. I don't think that it's right because my > 'nasty' hack changes that to \includegraphics{/img}, no? ??? It replaces the filename in the .fig file, not the filename in the .pstex_t file. The latter is wrong, the .fig file is ok. Now I get confused ;-) > I tried to start wrapping all this up in a class (filename) but got lost > in the intricacies. I still think that doing so would make life a lot > easier. Probably, but I am not so sure about the "lot". And this class can certainly not be used in figtools.sh! Georg
[PATCH] fixed
Hi! Not my day today. The ids+maths-patch still has the compile errors. Here's the corrected one. /Andreas Index: src/paragraph.C === RCS file: /cvs/lyx/lyx-devel/src/paragraph.C,v retrieving revision 1.380 diff -u -p -r1.380 paragraph.C --- src/paragraph.C 2004/10/07 15:21:03 1.380 +++ src/paragraph.C 2004/10/21 07:35:03 @@ -1338,7 +1338,7 @@ string Paragraph::getDocbookId() const InsetBase const * inset = getInset(i); InsetBase::Code lyx_code = inset->lyxCode(); if (lyx_code == InsetBase::LABEL_CODE) { - return static_cast(inset)->getContents(); + return sgml::cleanID(static_cast(inset)->getContents()); } } Index: src/sgml.C === RCS file: /cvs/lyx/lyx-devel/src/sgml.C,v retrieving revision 1.15 diff -u -p -r1.15 sgml.C --- src/sgml.C 2004/05/14 15:47:35 1.15 +++ src/sgml.C 2004/10/21 07:35:03 @@ -12,17 +12,20 @@ #include #include "support/std_ostream.h" +#include "support/lstrings.h" +#include "support/tostr.h" #include "paragraph.h" #include "sgml.h" +#include + +using lyx::support::subst; using std::endl; using std::make_pair; using std::ostream; using std::pair; using std::string; - +using std::map; namespace sgml { @@ -138,4 +141,76 @@ unsigned int closeEnvTags(ostream & os, } +std::string cleanID(std::string const & orig, std::string const & allowed) +{ + // The standard DocBook SGML declaration only allows letters, + // digits, '-' and '.' in a name. + // Since users might change that declaration one has to cater + // for additional allowed characters. + // This routine replaces illegal characters by '-' or '.' + // and adds a number for uniqueness. + // If you know what you are doing, you can set allowed=="all" + // to disable this mangling. + + string::const_iterator it = orig.begin(); + string::const_iterator end = orig.end(); + + string content; + + if (allowed == "all") { + return orig; + } + + typedef map MangledMap; + static MangledMap mangledNames; + static int mangleID = 1; + + MangledMap::const_iterator const known = mangledNames.find(orig); + if (known != mangledNames.end()) + return (*known).second; + + // make sure it starts with a letter + if (!isalpha(*it) && allowed.find(*it) >= allowed.size()) + content += "x"; + + bool mangle = false; + for (; it != end; ++it) { + char c = *it; + if (isalpha(c) || isdigit(c) || c == '-' || c == '.' || allowed.find(c) < allowed.size()) + content += c; + else if (c == '_' || c == ' ') { + mangle = true; + content += "-"; + } + else if (c == ':' || c == ',' || c == ';' || c == '!') { + mangle = true; + content += "."; + } + else { + mangle = true; + } + } + if (mangle) { + content += "-" + tostr(mangleID++); + } + else if (isdigit(content[content.size()-1])) { + content += "."; + } + + mangledNames[orig] = content; + + return content; +} + +std::string escapeEntities(std::string const & orig, char quote = '"') +{ + std::string result = subst(subst(orig,"&","&"),"<","<"); + if (quote == '"') + return subst(result, "\"", """); + else if (quote == '\'') + return subst(result,"'", "'"); + else + return result; +} } // namespace sgml Index: src/sgml.h === RCS file: /cvs/lyx/lyx-devel/src/sgml.h,v retrieving revision 1.12 diff -u -p -r1.12 sgml.h --- src/sgml.h 2004/04/03 08:37:01 1.12 +++ src/sgml.h 2004/10/21 07:35:04 @@ -27,12 +27,12 @@ namespace sgml { */ std::pair escapeChar(char c); -/// FIXME +/// FIXME int openTag(std::ostream & os, lyx::depth_type depth, bool mixcont, std::string const & latexname, std::string const & latexparam = std::string()); -/// FIXME +/// FIXME int closeTag(std::ostream & os, lyx::depth_type depth, bool mixcont, std::string const & latexname); @@ -42,6 +42,12 @@ unsigned int closeEnvTags(std::ostream & std::string const & environment_inner_depth, std::string const & item_tag, lyx::depth_type total_depth); + +/// replaces illegal chars like ':' or '_' from SGML ID attributes +std::string cleanID(std::string const & orig, std::string co
Re: A real prblem with XFig images
Georg Baum wrote: > Angus Leeming wrote: > >> Let me try and get my head around the various possibilities. Let's store >> the .fig file in the lyx document as 'images/img1.fig'. In turn, this >> .fig file references 'raw.eps', so the path to 'raw.eps' from the >> document directory is 'images/raw.eps' and the absolute path is >> '/images/raw.eps'. >> >> 1. Run View->PS etc. >> The 'images/img1.fig' is copied to the /tmp directory and this >> copy is >> modified there to contain '/images/raw.eps'. XFig will >> be happy and all will be well. We'll see the raw.eps image in the final >> PS file. > > Yes. Note that raw.eps is already included (not referenced) in > .eps in the temp dir. Oh, cool. I sort of new that already, but thanks for reminding me. >> 2. Export->Latex >> buffer.tex will include the snippet: >> \input{images/img.pstex_t} >> It is the user's responsibility to generate 'images/img.pstex_t' >> correctly. > > No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and > 'images/img.eps.' This is alo a case where the converter is called on the > original file and therefore modifies it :-((( Not so. It modifies a COPY of the original file. That's a big difference. Ok, so the bottom line is that a call to Export->Latex results in everything that would be needed to compile buffer.tex being placed in the /tmp/lyx_tmp.../lyx_tmpbuf0/ directory? The only conceptual problem thereafter is working out which of these files to 'return' in a 'buffer_latex' directory. (This is something we don't do but maybe should consider doing in the future?) > Another problem is that fig2pstex.sh does not know of latex's stupid > interpretation of relative filenames (relative to the master document, > not the included one. Therefore images/img.pstex_t contains > \includegraphics{img}, and this fails of course. Ok, I understand your point. I don't think that it's right because my 'nasty' hack changes that to \includegraphics{/img}, no? >> 2. Export->DVI >> Should the DVI file reference 'images/raw.eps' or '> buffer>/images/raw.eps' > > None of these two. It references the mangled name of 'images/img.eps', > because the dvi is created in the temp dir. Good. > I hope you are not anymore. I have the feeling that all this stuff is all more complicated than it needs to be. Our concept of a file is actually quite involved. // If filename is an absolute path then it can be found with // no other information. string filename; // If, however, filename is a relative path, then we should // look for it relative to the buffer path. string buffer_path; // If we don't find it there, then we should look for it // relative to some environment-variable specified path. string environment_variable There's probably other stuff involved too, including the phase of the moon and the color of the Luke Skywalker's light sabre. I tried to start wrapping all this up in a class (filename) but got lost in the intricacies. I still think that doing so would make life a lot easier. -- Angus
Re: [PATCH]
On Thu, Oct 21, 2004 at 10:30:05AM +0200, Andreas Vox wrote: > Hi! > > Another small and independent patch which corrects the behaviour > of starsection in DocBook. The other patch nested an inner > element into the , which is against DocBook DTD. > > /Andreas You are right, the content model is different from that of chapters/sections. Again as soon as I have the patch I will apply it directly. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: How to resolve relyx bugs?
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> What shall I do with relyx bugs that are fixed in tex2lyx (e.g. Georg> http://bugzilla.lyx.org/show_bug.cgi?id=1620 )? FIXED (because Georg> it works in tex2lyx) or WONTFIX (because it will not be fixed Georg> in relyx)? We could maybe introduce a new fixedintex2lyx flag. John is the authority when it comes to inventing flags for bugzilla, though. Of course, if tex2lyx is set to be the default converter for 1.4.0cvs, we can use fixedintrunk. JMarc
Re: [PATCH} Docbook citation
On Thu, Oct 21, 2004 at 10:23:29AM +0200, Andreas Vox wrote: > Hi! > > This is a small and independent patch which was already discussed. As soon as I have the patch I will apply it to my local tree. -- José Abílio Matos LyX and docbook a perfect match. :-)
How to resolve relyx bugs?
What shall I do with relyx bugs that are fixed in tex2lyx (e.g. http://bugzilla.lyx.org/show_bug.cgi?id=1620 )? FIXED (because it works in tex2lyx) or WONTFIX (because it will not be fixed in relyx)? Georg
Re: A real prblem with XFig images
Angus Leeming wrote: > Let me try and get my head around the various possibilities. Let's store > the .fig file in the lyx document as 'images/img1.fig'. In turn, this .fig > file references 'raw.eps', so the path to 'raw.eps' from the document > directory is 'images/raw.eps' and the absolute path is > '/images/raw.eps'. > > 1. Run View->PS etc. > The 'images/img1.fig' is copied to the /tmp directory and this > copy is > modified there to contain '/images/raw.eps'. XFig will be > happy and all will be well. We'll see the raw.eps image in the final PS > file. Yes. Note that raw.eps is already included (not referenced) in .eps in the temp dir. > 2. Export->Latex > buffer.tex will include the snippet: > \input{images/img.pstex_t} > It is the user's responsibility to generate 'images/img.pstex_t' > correctly. No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and 'images/img.eps.' This is alo a case where the converter is called on the original file and therefore modifies it :-((( Another problem is that fig2pstex.sh does not know of latex's stupid interpretation of relative filenames (relative to the master document, not the included one. Therefore images/img.pstex_t contains \includegraphics{img}, and this fails of course. I guess we have to do these conversions in the temp dir, too. > 2. Export->DVI > Should the DVI file reference 'images/raw.eps' or ' buffer>/images/raw.eps' None of these two. It references the mangled name of 'images/img.eps', because the dvi is created in the temp dir. > 3. Being nasty. Export->DVI but 'images/img1.fig' contains a reference to > 'images/raw.jpg'. XFig is clever enough to handle this. There should be no difference to 2. > H. I guess I'm a little confused by this all. I hope you are not anymore. Georg
Re: [PATCH] DocBook cleanID and math
On Thu, Oct 21, 2004 at 03:11:05PM +0100, José Abílio Oliveira Matos wrote: > > You can send send the different patches attached in the same message, since > the existing can be read. AS Chris says ;-), I'm not complaing about you but about the patches. :-) Also due to the wrap rules some lines are broken, and patch doesn't like them. It is easier for all if I ask you to send me the files instead of having all the work to reconstruct the patches. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] DocBook cleanID and math
On Thu, Oct 21, 2004 at 10:21:56AM +0200, Andreas Vox wrote: > Hi! > > I submit my patch from last weekend again with bug fixes and split into > parts. Please send the files not inline. It has been a hell trying to submit them to patch. You can send send the different patches attached in the same message, since the existing can be read. Thanks, -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] DocBook cleanID and math
Georg Baum <[EMAIL PROTECTED]> writes: < I did not understand it like that. I always thought that the policy on this < list was to put one change in one patch, e.g. one patch with the cleanId < change and one with the improved graphics output for docbook. I learned about this policy the hard way ... :-) < This has not < so much to do with applyable or not, but with the fact that it is easyer to < understand the changes with separate patches. In case you have several < changes that build on each other, first reach a consensus on the first one, < get somebody to apply it, then send the next etc. Yes, but it was weekend and I didn't want to stop coding! Ciao /Andreas
Re: A real prblem with XFig images
Georg Baum wrote: > Angus Leeming wrote: > >> I therefore suggest a new token '$$orig_i', being the name of the >> original file from which '$$i' was copied into the temp directory. Ok? > > For me, yes. > >> Now, Georg, could you expand on your ideas for when this magic should >> and should not be invoked? I'm afraid I don't see why it shouldn't be >> used every time that fig2pstex.sh is called. > > As long as the input is always in the temp dir, it is of course safe. The > external and graphics inset call the converter only on files in the temp > dir, so it should work. However, I have a general bad feeling if > something that is supposed to read from 'a' and write to 'b' is modifying > 'a' as a side effect. So this should at least be documented in > fig2xxxtex.sh. Let me try and get my head around the various possibilities. Let's store the .fig file in the lyx document as 'images/img1.fig'. In turn, this .fig file references 'raw.eps', so the path to 'raw.eps' from the document directory is 'images/raw.eps' and the absolute path is '/images/raw.eps'. 1. Run View->PS etc. The 'images/img1.fig' is copied to the /tmp directory and this copy is modified there to contain '/images/raw.eps'. XFig will be happy and all will be well. We'll see the raw.eps image in the final PS file. 2. Export->Latex buffer.tex will include the snippet: \input{images/img.pstex_t} It is the user's responsibility to generate 'images/img.pstex_t' correctly. 2. Export->DVI Should the DVI file reference 'images/raw.eps' or '/images/raw.eps' 3. Being nasty. Export->DVI but 'images/img1.fig' contains a reference to 'images/raw.jpg'. XFig is clever enough to handle this. H. I guess I'm a little confused by this all. Angus
Re: [patch] bug 1523 (LyX 1.3.x)
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> http://bugzilla.lyx.org/show_bug.cgi?id=1523 This bug is Juergen> already fixed (properly) in 1.4. I know that the attached Juergen> patch for 1.3.x is an ugly hack, but it works. Fixing this bug would be a very good idea indeed. What the reason why you choose this way instead of replicating 1.4.0 code? Do you think it is safer? JMarc
Re: A real prblem with XFig images
Angus Leeming wrote: > I therefore suggest a new token '$$orig_i', being the name of the original > file from which '$$i' was copied into the temp directory. Ok? For me, yes. > Now, Georg, could you expand on your ideas for when this magic should and > should not be invoked? I'm afraid I don't see why it shouldn't be used > every time that fig2pstex.sh is called. As long as the input is always in the temp dir, it is of course safe. The external and graphics inset call the converter only on files in the temp dir, so it should work. However, I have a general bad feeling if something that is supposed to read from 'a' and write to 'b' is modifying 'a' as a side effect. So this should at least be documented in fig2xxxtex.sh. I think for now your solution is fine. I might try my other idea with the converter "from x to x in temp dir" later. Of course it would make use of figtools.sh, and the other modifications will be minor, so your work does not get lost even if we'll switch to the other solution. Georg
Re: [patch] bug 1523 (LyX 1.3.x)
Juergen Spitzmueller wrote: > http://bugzilla.lyx.org/show_bug.cgi?id=1523 > > This bug is already fixed (properly) in 1.4. I know that the attached > patch for 1.3.x is an ugly hack, but it works. > > Jürgen Urrrggg #include #include ostringstream buffer; buffer << abs(static_cast(val_/100)) << '.' << std::setw(2) << std::setfill('0') << abs(static_cast(val_)%100); switch (unit_) { case PTW: buffer << "\\textwidth"; beak; case PCW: buffer << "\\columnwidth"; beak; case PPW: buffer << "\\paperwidth"; beak; case PLW: buffer << "\\linewidth"; beak; case PPH: buffer << "\\paperheight"; beak; case PTH: buffer << "\\textheight"; beak; default: -- Angus
[patch] bug 1523 (LyX 1.3.x)
http://bugzilla.lyx.org/show_bug.cgi?id=1523 This bug is already fixed (properly) in 1.4. I know that the attached patch for 1.3.x is an ugly hack, but it works. Jürgen Index: src/lyxlength.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlength.C,v retrieving revision 1.26 diff -u -r1.26 lyxlength.C --- src/lyxlength.C 4 Dec 2002 02:57:14 - 1.26 +++ src/lyxlength.C 21 Oct 2004 12:34:45 - @@ -59,30 +59,36 @@ string const LyXLength::asLatexString() const { + // a hack. LaTeX strings for values < 10 are calculated wrongly + // (factor x10) [bug 1523]. This bug is fixed in 1.4 (jspitzm) + string fixp = ""; + if (val_ < 10.0) + fixp = "0"; + ostringstream buffer; switch (unit_) { case PTW: - buffer << abs(static_cast(val_/100)) << '.' + buffer << abs(static_cast(val_/100)) << '.' << fixp << abs(static_cast(val_)%100) << "\\textwidth"; break; case PCW: - buffer << abs(static_cast(val_/100)) << '.' + buffer << abs(static_cast(val_/100)) << '.' << fixp << abs(static_cast(val_)%100) << "\\columnwidth"; break; case PPW: - buffer << abs(static_cast(val_/100)) << '.' + buffer << abs(static_cast(val_/100)) << '.' << fixp << abs(static_cast(val_)%100) << "\\paperwidth"; break; case PLW: - buffer << abs(static_cast(val_/100)) << '.' + buffer << abs(static_cast(val_/100)) << '.' << fixp << abs(static_cast(val_)%100) << "\\linewidth"; break; case PPH: - buffer << abs(static_cast(val_/100)) << '.' + buffer << abs(static_cast(val_/100)) << '.' << fixp << abs(static_cast(val_)%100) << "\\paperheight"; break; case PTH: - buffer << abs(static_cast(val_/100)) << '.' + buffer << abs(static_cast(val_/100)) << '.' << fixp << abs(static_cast(val_)%100) << "\\textheight"; break; default:
Re: [PATCH] DocBook cleanID and math
Andreas Vox wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > >> Here I'm using the knode news reader and have no such problems. Me too. > AppleMail doesn't do news and I'm not accustomed to ThunderBird yet. I am sure that decent news readers exist for macs, too. > Hm, before others complained about: > a) having problems with MIME type application/octet-stream > b) replaced characters with text files > c) prefering easy-to-read (short) patches over applyable ones 'cause > they wouldn't apply them anyhow. I did not understand it like that. I always thought that the policy on this list was to put one change in one patch, e.g. one patch with the cleanId change and one with the improved graphics output for docbook. This has not so much to do with applyable or not, but with the fact that it is easyer to understand the changes with separate patches. In case you have several changes that build on each other, first reach a consensus on the first one, get somebody to apply it, then send the next etc. I did it like that with the temp file stuff. Georg
Re: [PATCH] DocBook cleanID and math
Angus Leeming wrote: > Don't worry too much. It's not as if they're hard to extract with a little > bit editing. patch knows how to read articles ;-) (doesn't answer them, though) Alfredo
Re: [PATCH] DocBook cleanID and math
Angus Leeming <[EMAIL PROTECTED]> writes: > Don't worry too much. It's not as if they're hard to extract with a little > bit editing. In fact you probably don't have to. Doesn't patch ignore leading garbage? /Andreas
Re: [PATCH] DocBook cleanID and math
Andreas Vox wrote: >> As for your patches, you should not post them inline but instead attach >> them as a separate file. Much, much easier for us to save to disk and >> apply. > > Hm, before others complained about: > a) having problems with MIME type application/octet-stream > b) replaced characters with text files > c) prefering easy-to-read (short) patches over applyable ones 'cause > they wouldn't apply them anyhow. > > Your's is > d) have applyable patches > > I'll see if I can find a solution (AppleMail obviously isn't) > which satisfies all :-) Don't worry too much. It's not as if they're hard to extract with a little bit editing. -- Angus
Re: A real prblem with XFig images
Jean-Marc Lasgouttes wrote: > Angus> Hmmm. I don't think I am suggesting 'too smart'. I'm suggesting > Angus> that we augment these tokens understood by the converters > > Angus> string const token_from("$$i"); string const > Angus> token_base("$$b"); string const token_to("$$o"); string const > Angus> token_path("$$p"); with string const > Angus> token_bufferpath("$$bufferpath"); > > Angus> why might that be a problem? > > Because $$bufferpath is too long wrt the other names. Use $$bp or > something instead. > > Does this answer your question? > JMarc > > PS: actually I agree with your other post about the fact that the special > code is in a separate script. Actually, it turns out that we don't need the path to the buffer. We need the path to the original .fig file as it's this that all relative names stored in the .fig file are relative to. Placing the attached file, figtools.sh, in lib/scripts and hacking fig2pdftex.sh, fig2pstex.sh, (buffer dir is 'tree2', .fig file is to found in 'acinus3D_11x11x22_boundary') works beautifully. Index: fig2pdftex.sh === # Fail silently if the file doesn't exist test -r $input || exit 0 +working_dir=`dirname $0` +test -r "${working_dir}/figtools.sh" && { +. "${working_dir}/figtools.sh" +manipulate_fig_file_if_needed \ +"$input" "$HOME/Acinus/docs/tree2/acinus3D_11x11x22_boundary" +} I therefore suggest a new token '$$orig_i', being the name of the original file from which '$$i' was copied into the temp directory. Ok? Now, Georg, could you expand on your ideas for when this magic should and should not be invoked? I'm afraid I don't see why it shouldn't be used every time that fig2pstex.sh is called. -- Angus figtools.sh Description: application/shellscript
Re: [PATCH] DocBook cleanID and math
Angus Leeming <[EMAIL PROTECTED]> writes: > Are you using the webmail interface to gmane (is there one?) Yes. http://news.gmane.org/ > Here I'm using the knode news reader and have no such problems. AppleMail doesn't do news and I'm not accustomed to ThunderBird yet. > As for your patches, you should not post them inline but instead attach > them as a separate file. Much, much easier for us to save to disk and > apply. Hm, before others complained about: a) having problems with MIME type application/octet-stream b) replaced characters with text files c) prefering easy-to-read (short) patches over applyable ones 'cause they wouldn't apply them anyhow. Your's is d) have applyable patches I'll see if I can find a solution (AppleMail obviously isn't) which satisfies all :-) /Andreas
Re: name characters in xml.
On Thu, Oct 21, 2004 at 12:08:22PM +0200, Chris Karakas wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> schrieb am 21.10.04 00:28:34: > > > > > And is it ok if I limit myself to ASCII for the time being? > > > > Yes, we are safe with ASCII, notice that standard allows more than that. > > If we restict our self to ASCII and then when supporting unicode lift this > > restriction, we are safe. It is simple and for 1.4 should be OK. > > > > Does this mean that we cannot do DocBook in, say, greek with LyX? In greek, certainly. I was refering to the name of labels. In SGML, the default SGML declaration that comes with the stylesheets, and other tools only accept for IDs and thus for labels: - . letter numbers This is independent of the language. > I have people who ask me how to translate my PHP-Nuke HOWTO > > http://www.karakas-online.de/EN-Book/ > > in greek, or hindu or chinese. What shall I tell them? Chinese should be OK with the the CJK version of LyX. Hindu, I don't know. The problem here is just lyx supporting the appropriate encoding. > That labels, URL texts etc. should stay in english? I just said labels, the url certainly doesn't have that restriction. Notice that the xml doesn't have this restriction. OTOH yesterday while playing with references in xml, the parser accepted é in a label, but fop would complain and refuse to work. > PS. That's no accusation. I am just trying to understand what will be possible > and what not with the current state of affairs in LyX 1.4.0. LyX 1.4.0 will not support unicode, that is planned for the next version. Then some of this isses will be simplified. > -- > > Regards > > Chris Karakas > http://www.karakas-online.de > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook graphic -> mediaobject
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes: > Andreas Vox <[EMAIL PROTECTED]> writes: > | - case LyXLength::PT: //< Point = 1/72.27in = 0.351mm > | + case LyXLength::PT: // Point = 1/72.27in = 0.351mm > | result << len.value() * 72 / 72.27 << "pt"; > > The '<' is there for a reason. Yes. The reason is I copy&pasted this comments from their declaration :-) > Don't remove them. (rather fix them to be '///<') Doxygen'ing case labels seems rather radical to me ;-) Cheers /Andreas
Re: name characters in xml.
Chris Karakas <[EMAIL PROTECTED]> writes: > > Josà AbÃlio Oliveira Matos <[EMAIL PROTECTED]> schrieb am 21.10.04 00:28:34: > > > > > And is it ok if I limit myself to ASCII for the time being? > > > > Yes, we are safe with ASCII, notice that standard allows more than that. > > If we restict our self to ASCII and then when supporting unicode lift this > > restriction, we are safe. It is simple and for 1.4 should be OK. > > > > Does this mean that we cannot do DocBook in, say, greek with LyX? > > I have people who ask me how to translate my PHP-Nuke HOWTO > > http://www.karakas-online.de/EN-Book/ > > in greek, or hindu or chinese. What shall I tell them? > > That labels, URL texts etc. should stay in english? I don't think there's a choice for DocBook SGML. As a last resort they could specify "allowedchars=all" but if I understood you correctly, they would have to do some heavy SGML declaration hacking to get their processor to eat this IDs. For DocBook XML I'm playing with the idea to _only_ mangle special chars from the first 128 ASCII positions (except -._: of course). This will not be perfect as the user could use illegal chars from the upper range, but they are unlikely to mess up further processing. UTF-8 might be a problem, though. I don't think that can be changed until LyX has full Unicode support. :-( > PS. That's no accusation. I am just trying to understand what will be possible > and what not with the current state of affairs in LyX 1.4.0. Just keep us informed of the needs and we will queue the RFEs :-) Ciao /Andreas
Re: [PATCH] DocBook cleanID and math
Andreas Vox wrote: > Georg Baum <[EMAIL PROTECTED]> writes: > >> Joining the list is an alternative, I don't know of any other one. But >> what is wrong with gmane? I use it all the time with no problems. > > Its more picky about style than some members of the LyX core team about > spaces ;-) > > "There's much mor quoted text than other, correct that!" > "You seem to be top posting, don't do that!" > > And the bad thing for patches: > > "Some line are longer than 80 characters, correct that!" Are you using the webmail interface to gmane (is there one?) Here I'm using the knode news reader and have no such problems. As for your patches, you should not post them inline but instead attach them as a separate file. Much, much easier for us to save to disk and apply. -- Angus
Re: [PATCH] Docbook export math/graphic/refs
Chris Karakas <[EMAIL PROTECTED]> writes: > Andreas Vox <[EMAIL PROTECTED]> schrieb am 20.10.04 19:25:22: > > > > > > Oh BTW, Chris, if you read this: > > what happens if the user activates '&' for names? > The user will get the & character in a label and the SGML parser will > complain that some "entity XYZ not defined", I guess. > But you know my stand on this: the user used "&" in a label, the user > has to draw all consequences of his action. The parser will > complain, the user will have a look into the exported SGML file, > the user will recognize his mistake and will correct it. '&' and '"' will be mangled unless the user explicitly named them in "allowedNameChars". If the user allowed them, they will still be replaced by & and " since otherwise the resulting file would not be parsable. > We now have > > The user asked for "this", but he got "that" with a warning. > > which I have agreed to as a compromise. > BTW, I had such problems with "<" and ">" in URL texts. > The parser would complain "entity XYZ not defined", I would > check the SGML file and say to myself "but of course!", then > go to the URL text and enter "& lt ;" instead of "<" - and > everything would be fine. Since '&', '<', '>' and '"' are part of the DocBook syntax we will escape them whereever they could be interpreted as SGML/XML. If you want to use SGML markup, you can use a LyX SGML layout for it. '<' and '>' shouldn't have any effect in attributes, so they are allowed there. I don't know if there is a clean way to use explicit entities in IDs or other attributes. If one day LyX reads back Docbook files, they would be replaced, so there wouldn't be a roundtrip experience, which is bad. So the only clean way is to put the whole element in a LyX SGML layout, then entities in attributes aren't a problem. I'm aware that this is not what you want, but I'm afraid you wont convince a majority to do otherwise. :-) If you have an important use case which needs unescaped '&' or '"' in atrribute values, tell us and we'll think of a solution. Cheers /Andreas
Re: name characters in xml.
José Abílio Oliveira Matos <[EMAIL PROTECTED]> schrieb am 21.10.04 00:28:34: > > > And is it ok if I limit myself to ASCII for the time being? > > Yes, we are safe with ASCII, notice that standard allows more than that. > If we restict our self to ASCII and then when supporting unicode lift this > restriction, we are safe. It is simple and for 1.4 should be OK. > Does this mean that we cannot do DocBook in, say, greek with LyX? I have people who ask me how to translate my PHP-Nuke HOWTO http://www.karakas-online.de/EN-Book/ in greek, or hindu or chinese. What shall I tell them? That labels, URL texts etc. should stay in english? PS. That's no accusation. I am just trying to understand what will be possible and what not with the current state of affairs in LyX 1.4.0. -- Regards Chris Karakas http://www.karakas-online.de
Re: [PATCH] Docbook export math/graphic/refs
José Abílio Oliveira Matos <[EMAIL PROTECTED]> schrieb am 20.10.04 21:47:14: > > The other point of Chris is: should lyx be clever and not tell the users > that it is fixing the document without the user's approval? Chris thinks > not, the lyx core team thinks otherwise. > > All the discussion comes to this. And only for sgml, not for xml. > Exactly. You brought it to the point. -- Regards Chris Karakas http://www.karakas-online.de
Re: [PATCH] DocBook cleanID and math
Georg Baum <[EMAIL PROTECTED]> writes: > Joining the list is an alternative, I don't know of any other one. But what > is wrong with gmane? I use it all the time with no problems. Its more picky about style than some members of the LyX core team about spaces ;-) "There's much mor quoted text than other, correct that!" "You seem to be top posting, don't do that!" And the bad thing for patches: "Some line are longer than 80 characters, correct that!" I'm not sure if the '===' line already triggers that, but sometimes there are long expressions which make lines too long (yes, I know, I should correct that in the source, make a new patch and try again -- but sometimes I don't have time for that). Otherwise gmane works fine. It does real threading, not just name matching as MARC (even if that means that some current posts are on page 4) /Andreas
Re: [PATCH] Docbook graphic -> mediaobject
Andreas Vox <[EMAIL PROTECTED]> writes: | Angus Leeming <[EMAIL PROTECTED]> writes: > | > You attached the insetcite patch... > | That's what happens if you start posting before waking up ... > | Sorry. | /Andreas > | - case LyXLength::PT: //< Point = 1/72.27in = 0.351mm | + case LyXLength::PT: // Point = 1/72.27in = 0.351mm | result << len.value() * 72 / 72.27 << "pt"; The '<' is there for a reason. Don't remove them. (rather fix them to be '///<') Think doxygen documentation. -- Lgb
Re: [PATCH] Docbook export math/graphic/refs
Andreas Vox <[EMAIL PROTECTED]> schrieb am 20.10.04 19:25:22: > > > Oh BTW, Chris, if you read this: > what happens if the user activates '&' for names? ;-) > > :-) The user will get the & character in a label and the SGML parser will complain that some "entity XYZ not defined", I guess. But you know my stand on this: the user used "&" in a label, the user has to draw all consequences of his action. The parser will complain, the user will have a look into the exported SGML file, the user will recognize his mistake and will correct it. The user asked for a "&" in a label, the user got it. And not: The user asked for "this", but he got "that". We now have The user asked for "this", but he got "that" with a warning. which I have agreed to as a compromise. BTW, I had such problems with "<" and ">" in URL texts. The parser would complain "entity XYZ not defined", I would check the SGML file and say to myself "but of course!", then go to the URL text and enter "& lt ;" instead of "<" - and everything would be fine. For example, in http://www.karakas-online.de/mySGML/openjade-errors.html (which is a document I created with LyX and its SGML export) I have a link with the URL text Definitive Guide to DocBook on the < entry > element Now, the way you want to do it, mangling labels and texts, how are you going to know that a "&" is a real "&" and not part of an "entity delimiter", as in "& lt ;"? You will end up trying to emulate an SGML parser, which is really not LyX' job. Note: I have inserted blanks in my strings, so that my webmail does not interprete them as real entities and filters them out. But I am sure you understand what I meant. ;-) -- Regards Chris Karakas http://www.karakas-online.de
Re: [PATCH] DocBook cleanID and math
Andreas Vox wrote: > Does anyone know how to post followups except using gmane? > Maybe I should join the mailing list. Right now I have to choose > between loosing the thread reference or not beeing able to post > long lines. Joining the list is an alternative, I don't know of any other one. But what is wrong with gmane? I use it all the time with no problems. Georg
Re: [PATCH] DocBook cleanID and math
Andreas Vox <[EMAIL PROTECTED]> writes: > > Hi! > > I submit my patch from last weekend again with bug fixes and split into > parts. And it also features some last-minute compile time errors in sgml.C :-( It needs a "using lyx::support::subst;" line at top and a superflous '}' must be deleted at the end of the file. Sorry. Does anyone know how to post followups except using gmane? Maybe I should join the mailing list. Right now I have to choose between loosing the thread reference or not beeing able to post long lines. /Andreas
Re: [PATCH] Docbook starsections
Andreas Vox <[EMAIL PROTECTED]> writes: > It's not so secret that I'd have to omit the subject line ... :-) /Andreas
[PATCH] Changelogs for the other Docbook patches
Hi! I bundled those extra since they relate to all other patches. This time I didn't erase any blanks but replaced all blanks by double blanks, as is required for the Changelog format ;-) Josè, could you commit these patches? I want to go on with the allowedNameChars runparam, DBTeXMath, calling 'escapeEntities' where needed and further debugging. It just feels wrong when my version gets far off the CVS version and my patches get larger and more interconnected. /Andreas Index: src/ChangeLog === RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v retrieving revision 1.1993 diff -u -p -r1.1993 ChangeLog --- src/ChangeLog 2004/10/19 09:11:00 1.1993 +++ src/ChangeLog 2004/10/21 07:34:59 @@ -1,3 +1,11 @@ +2004-10-18 Andreas Vox <[EMAIL PROTECTED]> + + * Buffer.C (makeDocBookFile): add Dsssl Stylesheet control + entities to preamble + * Paragraph.C (getDocbookId): clean illegal chars in ID + * sgml.[hC] (cleanID): new function to replace special chars + by mangled versions in SGML IDs + 2004-10-18 Georg Baum <[EMAIL PROTECTED]> * messages.C (Pimpl): strip off translation context information Index: src/output_docbook.C === RCS file: /cvs/lyx/lyx-devel/src/output_docbook.C,v retrieving revision 1.11 diff -u -p -r1.11 output_docbook.C --- src/output_docbook.C2004/10/13 22:15:32 1.11 +++ src/output_docbook.C2004/10/21 07:35:02 @@ -95,7 +95,7 @@ void docbookParagraphs(Buffer const & bu string ls = par->getDocbookId(); if (!ls.empty()) - ls = " id = \"" + ls + "\""; + ls = " id=\"" + ls + "\""; // Write opening SGML tags. switch (style->latextype) { Index: src/insets/ChangeLog === RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v retrieving revision 1.1050 diff -u -p -r1.1050 ChangeLog --- src/insets/ChangeLog 2004/10/05 13:38:30 1.1050 +++ src/insets/ChangeLog 2004/10/21 07:35:12 @@ -1,3 +1,12 @@ +2004-17-05 Andreas Vox <[EMAIL PROTECTED]> + + * insetref.C (docbook): clean illegal chars in ID + * insetlabel.C (docbook): clean illegal chars in ID +* insetgraphics.C (docbook, writeImageObject): write more than + one format of imageobjects in +* insetcite.[hC] (docbook, latex, cleanupWhitespace): implementing +DocBook output for this inset ( content ) + 2004-10-05 Andreas Vox <[EMAIL PROTECTED]> * insetgraphics.C (docbook) : using mediaobject for XML; Index: src/mathed/ChangeLog === RCS file: /cvs/lyx/lyx-devel/src/mathed/ChangeLog,v retrieving revision 1.444 diff -u -p -r1.444 ChangeLog --- src/mathed/ChangeLog 2004/10/17 20:06:35 1.444 +++ src/mathed/ChangeLog 2004/10/21 07:35:16 @@ -1,3 +1,15 @@ +2004-10-20 Andreas Vox <[EMAIL PROTECTED]> + + * math_ref_inset.C (docbook): escape '&' and '<' in content + +2004-10-18 Andreas Vox <[EMAIL PROTECTED]> + + * math_ref_inset.C (docbook): clean illegal chars in ID, fix XML endtag + * math_hullInset.C (docbook): clean illegal chars in ID + * math_hullInset.C (docbook): reversed order of and elements + * math_hullinset.C (docbook): write for Docbook + where ".." is either the first label or a generated name. + 2004-10-15 Georg Baum <[EMAIL PROTECTED]> * math_hullinset.C (mutate): fix endless loop for unknown types
Re: [PATCH] Docbook graphic -> mediaobject
Andreas Vox wrote: > Hi! > > This is the insetgraphics patch, which also changes the Docbook SGML > preamble. Nothing new, except that I not only erased all blanks but also > some superflous '<' chars :-) You attached the insetcite patch... -- Angus
[PATCH]
Hi! Another small and independent patch which corrects the behaviour of starsection in DocBook. The other patch nested an inner element into the , which is against DocBook DTD. /Andreas Index: lib/layouts/db_stdstarsections.inc === RCS file: /cvs/lyx/lyx-devel/lib/layouts/db_stdstarsections.inc,v retrieving revision 1.5 diff -u -p -r1.5 db_stdstarsections.inc --- lib/layouts/db_stdstarsections.inc 2004/10/15 16:22:43 1.5 +++ lib/layouts/db_stdstarsections.inc 2004/10/21 07:34:43 @@ -14,7 +14,7 @@ Style Part* MarginStatic LatexName bridgehead LatexType Environment - InnerTag title + InnerTag !-- -- LabelType No_Label LatexParamrenderas="part" End @@ -24,7 +24,7 @@ Style Chapter* CopyStyle Chapter MarginStatic LatexType Environment - InnerTag title + InnerTag !-- -- LatexName bridgehead LabelType No_Label OptionalArgs 0 @@ -37,7 +37,7 @@ Style Section* MarginStatic LatexName bridgehead LatexType Environment - InnerTag title + InnerTag !-- -- LabelType No_Label OptionalArgs 0 LatexParamrenderas="sect1" @@ -49,7 +49,7 @@ Style Subsection* MarginStatic LatexName bridgehead LatexType Environment - InnerTag title + InnerTag !-- -- LabelType No_Label OptionalArgs 0 LatexParamrenderas="sect2" @@ -61,7 +61,7 @@ Style Subsubsection* MarginStatic LatexName bridgehead LatexType Environment - InnerTag title + InnerTag !-- -- LabelType No_Label OptionalArgs 0 LatexParamrenderas="sect3" @@ -73,7 +73,7 @@ Style Paragraph* MarginStatic LatexName bridgehead LatexType Environment - InnerTag title + InnerTag !-- -- LabelType No_Label OptionalArgs 0 LatexParamrenderas="sect4" @@ -85,7 +85,7 @@ Style Subparagraph* MarginStatic LatexName bridgehead LatexType Environment - InnerTag title + InnerTag !-- -- LabelType No_Label OptionalArgs 0 LatexParamrenderas="sect5"
[PATCH] Docbook graphic -> mediaobject
Hi! This is the insetgraphics patch, which also changes the Docbook SGML preamble. Nothing new, except that I not only erased all blanks but also some superflous '<' chars :-) /Andreas Index: src/insets/insetcite.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetcite.C,v retrieving revision 1.86 diff -u -p -r1.86 insetcite.C --- src/insets/insetcite.C 2004/10/05 10:11:41 1.86 +++ src/insets/insetcite.C 2004/10/21 07:35:12 @@ -324,6 +324,35 @@ int InsetCitation::plaintext(Buffer cons } +namespace { + +string const cleanupWhitespace(string const & citelist) +{ + string::const_iterator it = citelist.begin(); + string::const_iterator end = citelist.end(); + // Paranoia check: make sure that there is no whitespace in here + // -- at least not behind commas or at the beginning + string result; + char last = ','; + for (; it != end; ++it) { + if (*it != ' ') + last = *it; + if (*it != ' ' || last != ',') + result += *it; + } + return result; +} + +// end anon namyspace +} + +int InsetCitation::docbook(Buffer const &, ostream & os, OutputParams const &) const +{ + os << "" << cleanupWhitespace(getContents()) << ""; + return 0; +} + + // Have to overwrite the default InsetCommand method in order to check that // the \cite command is valid. Eg, the user has natbib enabled, inputs some // citations and then changes his mind, turning natbib support off. The output @@ -343,20 +372,8 @@ int InsetCitation::latex(Buffer const & os << '[' << before << "][" << after << ']'; else if (!after.empty()) os << '[' << after << ']'; - - string::const_iterator it = getContents().begin(); - string::const_iterator end = getContents().end(); - // Paranoia check: make sure that there is no whitespace in here - string content; - char last = ','; - for (; it != end; ++it) { - if (*it != ' ') - last = *it; - if (*it != ' ' || last != ',') - content += *it; - } - os << '{' << content << '}'; + os << '{' << cleanupWhitespace(getContents()) << '}'; return 0; } Index: src/insets/insetcite.h === RCS file: /cvs/lyx/lyx-devel/src/insets/insetcite.h,v retrieving revision 1.52 diff -u -p -r1.52 insetcite.h --- src/insets/insetcite.h 2004/08/14 18:41:27 1.52 +++ src/insets/insetcite.h 2004/10/21 07:35:13 @@ -40,6 +40,9 @@ public: int latex(Buffer const &, std::ostream &, OutputParams const &) const; /// + int docbook(Buffer const &, std::ostream &, + OutputParams const &) const; + /// void validate(LaTeXFeatures &) const; private:
[PATCH} Docbook citation
Hi! This is a small and independent patch which was already discussed. /Andreas Index: src/insets/insetcite.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetcite.C,v retrieving revision 1.86 diff -u -p -r1.86 insetcite.C --- src/insets/insetcite.C 2004/10/05 10:11:41 1.86 +++ src/insets/insetcite.C 2004/10/21 07:35:12 @@ -324,6 +324,35 @@ int InsetCitation::plaintext(Buffer cons } +namespace { + +string const cleanupWhitespace(string const & citelist) +{ + string::const_iterator it = citelist.begin(); + string::const_iterator end = citelist.end(); + // Paranoia check: make sure that there is no whitespace in here + // -- at least not behind commas or at the beginning + string result; + char last = ','; + for (; it != end; ++it) { + if (*it != ' ') + last = *it; + if (*it != ' ' || last != ',') + result += *it; + } + return result; +} + +// end anon namyspace +} + +int InsetCitation::docbook(Buffer const &, ostream & os, OutputParams const &) const +{ + os << "" << cleanupWhitespace(getContents()) << ""; + return 0; +} + + // Have to overwrite the default InsetCommand method in order to check that // the \cite command is valid. Eg, the user has natbib enabled, inputs some // citations and then changes his mind, turning natbib support off. The output @@ -343,20 +372,8 @@ int InsetCitation::latex(Buffer const & os << '[' << before << "][" << after << ']'; else if (!after.empty()) os << '[' << after << ']'; - - string::const_iterator it = getContents().begin(); - string::const_iterator end = getContents().end(); - // Paranoia check: make sure that there is no whitespace in here - string content; - char last = ','; - for (; it != end; ++it) { - if (*it != ' ') - last = *it; - if (*it != ' ' || last != ',') - content += *it; - } - os << '{' << content << '}'; + os << '{' << cleanupWhitespace(getContents()) << '}'; return 0; } Index: src/insets/insetcite.h === RCS file: /cvs/lyx/lyx-devel/src/insets/insetcite.h,v retrieving revision 1.52 diff -u -p -r1.52 insetcite.h --- src/insets/insetcite.h 2004/08/14 18:41:27 1.52 +++ src/insets/insetcite.h 2004/10/21 07:35:13 @@ -40,6 +40,9 @@ public: int latex(Buffer const &, std::ostream &, OutputParams const &) const; /// + int docbook(Buffer const &, std::ostream &, + OutputParams const &) const; + /// void validate(LaTeXFeatures &) const; private:
[PATCH] DocBook cleanID and math
Hi! I submit my patch from last weekend again with bug fixes and split into parts. This one is the biggest, it contains the changes to math_hullinset and the new 'cleanID' function. Content: * calling 'sgml::cleanID' when outputting SGML or XML ids or linkends. * changing the namemangling in 'cleanID' to be unique and according to SGML decl. * mathed: escaping '&' and '<' in output * element for equations Oh yes, and I made a :%s/ // in vi, so there shouldn't be any superflous spaces left ;-) /Andreas Index: src/paragraph.C === RCS file: /cvs/lyx/lyx-devel/src/paragraph.C,v retrieving revision 1.380 diff -u -p -r1.380 paragraph.C --- src/paragraph.C 2004/10/07 15:21:03 1.380 +++ src/paragraph.C 2004/10/21 07:35:03 @@ -1338,7 +1338,7 @@ string Paragraph::getDocbookId() const InsetBase const * inset = getInset(i); InsetBase::Code lyx_code = inset->lyxCode(); if (lyx_code == InsetBase::LABEL_CODE) { -return static_cast(inset)->getContents(); +return sgml::cleanID(static_cast(inset)->getContents()); } } Index: src/sgml.C === RCS file: /cvs/lyx/lyx-devel/src/sgml.C,v retrieving revision 1.15 diff -u -p -r1.15 sgml.C --- src/sgml.C 2004/05/14 15:47:35 1.15 +++ src/sgml.C 2004/10/21 07:35:03 @@ -12,17 +12,20 @@ #include #include "support/std_ostream.h" +#include "support/lstrings.h" +#include "support/tostr.h" #include "paragraph.h" #include "sgml.h" +#include + using std::endl; using std::make_pair; using std::ostream; using std::pair; using std::string; - +using std::map; namespace sgml { @@ -138,4 +141,76 @@ unsigned int closeEnvTags(ostream & os, } +std::string cleanID(std::string const & orig, std::string const & allowed) +{ + // The standard DocBook SGML declaration only allows letters, + // digits, '-' and '.' in a name. + // Since users might change that declaration one has to cater + // for additional allowed characters. + // This routine replaces illegal characters by '-' or '.' + // and adds a number for uniqueness. + // If you know what you are doing, you can set allowed=="all" + // to disable this mangling. + + string::const_iterator it = orig.begin(); + string::const_iterator end = orig.end(); + + string content; + + if (allowed == "all") { + return orig; + } + + typedef map MangledMap; + static MangledMap mangledNames; + static int mangleID = 1; + + MangledMap::const_iterator const known = mangledNames.find(orig); + if (known != mangledNames.end()) + return (*known).second; + + // make sure it starts with a letter + if (!isalpha(*it) && allowed.find(*it) >= allowed.size()) + content += "x"; + + bool mangle = false; + for (; it != end; ++it) { + char c = *it; + if (isalpha(c) || isdigit(c) || c == '-' || c == '.' || allowed.find(c) < allowed.size()) + content += c; + else if (c == '_' || c == ' ') { + mangle = true; + content += "-"; + } + else if (c == ':' || c == ',' || c == ';' || c == '!') { + mangle = true; + content += "."; + } + else { + mangle = true; + } + } + if (mangle) { + content += "-" + tostr(mangleID++); + } + else if (isdigit(content[content.size()-1])) { + content += "."; + } + + mangledNames[orig] = content; + + return content; +} + +std::string escapeEntities(std::string const & orig, char quote = '"') +{ + std::string result = subst(subst(orig,"&","&"),"<","<"); + if (quote == '"') + return subst(result, "\"", """); + else if (quote == '\'') + return subst(result,"'", "'"); + else + return result; +} +} } // namespace sgml Index: src/sgml.h === RCS file: /cvs/lyx/lyx-devel/src/sgml.h,v retrieving revision 1.12 diff -u -p -r1.12 sgml.h --- src/sgml.h 2004/04/03 08:37:01 1.12 +++ src/sgml.h 2004/10/21 07:35:04 @@ -27,12 +27,12 @@ namespace sgml { */ std::pair escapeChar(char c); -/// FIXME +/// FIXME int openTag(std::ostream & os, lyx::depth_type depth, bool mixcont, std::string const & latexname, std::string const & latexparam = std::string()); -/// FIXME +/// FIXME int closeTag(std::ostream & os, lyx::depth_type depth, bool mixcont, std::string const & latexname); @@ -42,6 +42,12 @@ unsigned int closeEnvTags(std::ostream & std::string const & environment_inner_depth, std::string const & item_tag, lyx::depth_type total_depth); + +/// replaces illegal chars like ':' or '_' from SGML ID attributes +std::string cleanID(std::string const & orig, std::string const & allowed = std::string()); + +/// escapes & and < +std::string escapeEntities(std::string const & orig, char quote = '"'); } Index: src/insets/insetlabel.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetlabel.C,v retrieving revision 1.95 diff -u -p -r1.95 insetlabel.C --- src/insets/insetlabel.C 2004/05/14 15:47:35
Re: [patch] fix bug 1620
On Thu, Oct 21, 2004 at 09:19:38AM +0200, Georg Baum wrote: > > I had this already set on one machine, but obviously not on this one. I have > added it now. Unfortunately it would not have helped much in this case, > since parse_text() is a monster function ;-) Thanks. :-) > Georg -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [patch] fix bug 1620
José Abílio Oliveira Matos wrote: > Hi Georg, > > not related but I use in my $HOME/.cvsrc this: > > cvs -z6 > diff -upN > rdiff -upN > update -dP > > > My point is *p* option for diff, it allows to see the C/C++ function > where > the change takes place. Please consider using that it makes patches easier > to read, at least to me. :-) I had this already set on one machine, but obviously not on this one. I have added it now. Unfortunately it would not have helped much in this case, since parse_text() is a monster function ;-) Georg