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
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. :-)
[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 ALT role=tex output
* graphic 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_castInsetCommand const *(inset)-getContents();
+return sgml::cleanID(static_castInsetCommand const
*(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 config.h
#include support/std_ostream.h
+#include support/lstrings.h
+#include support/tostr.h
#include paragraph.h
#include sgml.h
+#include map
+
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 mapstring, string 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,,amp;),,lt;);
+ if (quote == '')
+ return subst(result, \, quot;);
+ else if (quote == '\'')
+ return subst(result,', apos;);
+ 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::pairbool, std::string 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
---
[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 citation cleanupWhitespace(getContents())
/citation;
+ 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 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 citation cleanupWhitespace(getContents())
/citation;
+ 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]
Hi! Another small and independent patch which corrects the behaviour of starsection in DocBook. The other patch nested an inner title element into the bridgehead, 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
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] 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 mediaobject
+* insetcite.[hC] (docbook, latex, cleanupWhitespace):
implementing
+DocBook output for this inset ( citationcontent/citation )
+
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 alt 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 math and alt
elements
+ * math_hullinset.C (docbook): write graphic filref=.. 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
Angus Leeming [EMAIL PROTECTED] writes:
You attached the insetcite patch...
That's what happens if you start posting before waking up ...
Sorry.
/Andreas
Index: src/buffer.C
===
RCS file: /cvs/lyx/lyx-devel/src/buffer.C,v
retrieving revision 1.584
diff -u -p -r1.584 buffer.C
--- src/buffer.C2004/10/09 21:32:55 1.584
+++ src/buffer.C2004/10/21 07:35:00
@@ -1089,6 +1089,13 @@ void Buffer::makeDocBookFile(string cons
ofs PUBLIC \-//OASIS//DTD DocBook V4.2//EN\;
string preamble = params().preamble;
+ if (runparams.flavor != OutputParams::XML ) {
+ preamble += !ENTITY % output.print.png \IGNORE\\n;
+ preamble += !ENTITY % output.print.pdf \IGNORE\\n;
+ preamble += !ENTITY % output.print.eps \IGNORE\\n;
+ preamble += !ENTITY % output.print.bmp \IGNORE\\n;
+ }
+
string const name = runparams.nice ?
ChangeExtension(pimpl_-filename, .sgml)
: fname;
preamble += features.getIncludedFiles(name);
Index: src/insets/insetgraphics.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.258
diff -u -p -r1.258 insetgraphics.C
--- src/insets/insetgraphics.C 2004/10/05 13:38:31 1.258
+++ src/insets/insetgraphics.C 2004/10/21 07:35:13
@@ -295,22 +295,22 @@ string const InsetGraphics::createLatexO
// before writing it to the output stream.
ostringstream options;
if (!params().bb.empty())
- optionsbb= rtrim(params().bb) ,\n;
+ options bb= rtrim(params().bb) ,\n;
if (params().draft)
- optionsdraft,\n;
+ options draft,\n;
if (params().clip)
- optionsclip,\n;
+ options clip,\n;
if (!float_equal(params().scale, 0.0, 0.05)) {
if (!float_equal(params().scale, 100.0, 0.05))
- optionsscale= params().scale / 100.0
+ options scale= params().scale / 100.0
,\n;
} else {
if (!params().width.zero())
- optionswidth= params().width.asLatexString() ,\n;
+ options width= params().width.asLatexString() ,\n;
if (!params().height.zero())
- optionsheight= params().height.asLatexString() ,\n;
+ options height= params().height.asLatexString() ,\n;
if (params().keepAspectRatio)
- optionskeepaspectratio,\n;
+ options keepaspectratio,\n;
}
// Make sure rotation angle is not very close to zero;
@@ -341,50 +341,50 @@ string const InsetGraphics::createLatexO
string const InsetGraphics::toDocbookLength(LyXLength const len)
const
{
ostringstream result;
- switch (len.unit() ) {
- case LyXLength::SP: // Scaled point (65536sp = 1pt) TeX's smallest
unit.
+ switch (len.unit()) {
+ case LyXLength::SP: // Scaled point (65536sp = 1pt) TeX's smallest
unit.
result len.value() * 65536.0 * 72 / 72.27 pt;
break;
- 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;
break;
- case LyXLength::BP: // Big point (72bp = 1in), also PostScript point
+ case LyXLength::BP: // Big point (72bp = 1in), also PostScript point
result len.value() pt;
break;
- case LyXLength::DD: // Didot point = 1/72 of a French inch, =
0.376mm
+ case LyXLength::DD: // Didot point = 1/72 of a French inch, = 0.376mm
result len.value() * 0.376 mm;
break;
- case LyXLength::MM: // Millimeter = 2.845pt
+ case LyXLength::MM: // Millimeter = 2.845pt
result len.value() mm;
break;
- case LyXLength::PC: // Pica = 12pt = 4.218mm
+ case LyXLength::PC: // Pica = 12pt = 4.218mm
result len.value() pc;
break;
- case LyXLength::CC: // Cicero = 12dd = 4.531mm
+ case LyXLength::CC: // Cicero = 12dd = 4.531mm
result len.value() * 4.531 mm;
break;
- case LyXLength::CM: // Centimeter = 10mm = 2.371pc
+ case LyXLength::CM: // Centimeter = 10mm = 2.371pc
result len.value() cm;
break;
- case LyXLength::IN: // Inch = 25.4mm = 72.27pt = 6.022pc
+ case LyXLength::IN: // Inch = 25.4mm = 72.27pt = 6.022pc
result len.value() in;
break;
- case LyXLength::EX: // Height of a small x for the current font.
+ case LyXLength::EX: // Height of a small x for the current font.
// Obviously we have to compromise here. Any better ratio than 1.5 ?
result len.value() / 1.5 em;
break;
- case LyXLength::EM: // Width of capital M in current font.
+ case LyXLength::EM: // Width of capital M in current font.
result len.value() em;
break;
- case LyXLength::MU: // Math unit (18mu = 1em) for positioning in
math mode
+ case LyXLength::MU: // Math unit (18mu = 1em) for positioning in
math mode
result len.value() * 18 em;
break;
- case LyXLength::PTW: // Percent of TextWidth
- case LyXLength::PCW: // Percent of ColumnWidth
- case LyXLength::PPW: // Percent of PageWidth
- case LyXLength::PLW: // Percent of LineWidth
- case LyXLength::PTH: // Percent of
Re: [PATCH] Docbook starsections
Andreas Vox [EMAIL PROTECTED] writes: It's not so secret that I'd have to omit the subject line ... :-) /Andreas
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 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 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 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 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: 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
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: [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: name characters in xml.
Chris Karakas [EMAIL PROTECTED] writes: Jos Ablio 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 graphic - mediaobject
Lars Gullik Bjnnes [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 copypasted 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.
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 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: 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
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: [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
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
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
[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_castint(val_/100)) '.'
+ buffer abs(static_castint(val_/100)) '.' fixp
abs(static_castint(val_)%100) \\textwidth;
break;
case PCW:
- buffer abs(static_castint(val_/100)) '.'
+ buffer abs(static_castint(val_/100)) '.' fixp
abs(static_castint(val_)%100) \\columnwidth;
break;
case PPW:
- buffer abs(static_castint(val_/100)) '.'
+ buffer abs(static_castint(val_/100)) '.' fixp
abs(static_castint(val_)%100) \\paperwidth;
break;
case PLW:
- buffer abs(static_castint(val_/100)) '.'
+ buffer abs(static_castint(val_/100)) '.' fixp
abs(static_castint(val_)%100) \\linewidth;
break;
case PPH:
- buffer abs(static_castint(val_/100)) '.'
+ buffer abs(static_castint(val_/100)) '.' fixp
abs(static_castint(val_)%100) \\paperheight;
break;
case PTH:
- buffer abs(static_castint(val_/100)) '.'
+ buffer abs(static_castint(val_/100)) '.' fixp
abs(static_castint(val_)%100) \\textheight;
break;
default:
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 iostream
#include iomanip
ostringstream buffer;
buffer abs(static_castint(val_/100)) '.'
std::setw(2) std::setfill('0')
abs(static_castint(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
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 == 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
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
'path to buffer/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 'path to buffer/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 'path to
buffer/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] 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: [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
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: 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
'path to buffer/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 'path to buffer/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
mangled file name of images/img1.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 'path to
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
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: [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. :-)
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]
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 title element into the bridgehead, 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: 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
'path to buffer/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 'path to buffer/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
mangled file name of images/img1.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{absolute path to/img}, no?
2. Export-DVI
Should the DVI file reference 'images/raw.eps' or 'path to
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
[PATCH] es for DocBook attached
Hi all!
My next patch(es) will be more orderly, promise!
/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 citation cleanupWhitespace(getContents()) /citation;
+ 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:
Index: src/buffer.C
===
RCS file: /cvs/lyx/lyx-devel/src/buffer.C,v
retrieving revision 1.584
diff -u -p -r1.584 buffer.C
--- src/buffer.C2004/10/09 21:32:55 1.584
+++ src/buffer.C2004/10/21 07:35:00
@@ -1089,6 +1089,13 @@ void Buffer::makeDocBookFile(string cons
ofs PUBLIC \-//OASIS//DTD DocBook V4.2//EN\;
string preamble = params().preamble;
+ if (runparams.flavor != OutputParams::XML ) {
+ preamble += !ENTITY % output.print.png \IGNORE\\n;
+ preamble += !ENTITY % output.print.pdf \IGNORE\\n;
+ preamble += !ENTITY % output.print.eps \IGNORE\\n;
+ preamble += !ENTITY % output.print.bmp \IGNORE\\n;
+ }
+
string const name = runparams.nice ? ChangeExtension(pimpl_-filename,
.sgml)
: fname;
preamble += features.getIncludedFiles(name);
Index: src/insets/insetgraphics.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.258
diff -u -p -r1.258 insetgraphics.C
--- src/insets/insetgraphics.C 2004/10/05 13:38:31 1.258
+++ src/insets/insetgraphics.C 2004/10/21 07:35:13
@@ -295,22 +295,22 @@ string const InsetGraphics::createLatexO
// before writing it to the output stream.
ostringstream options;
if (!params().bb.empty())
- optionsbb= rtrim(params().bb) ,\n;
+ options bb= rtrim(params().bb) ,\n;
if (params().draft)
- optionsdraft,\n;
+ options draft,\n;
if (params().clip)
- optionsclip,\n;
+ options clip,\n;
if (!float_equal(params().scale, 0.0, 0.05)) {
if (!float_equal(params().scale, 100.0, 0.05))
- optionsscale= params().scale / 100.0
+ options scale= params().scale / 100.0
,\n;
[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_castInsetCommand const
*(inset)-getContents();
+ return sgml::cleanID(static_castInsetCommand const
*(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 config.h
#include support/std_ostream.h
+#include support/lstrings.h
+#include support/tostr.h
#include paragraph.h
#include sgml.h
+#include map
+
+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 mapstring, string 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,,amp;),,lt;);
+ if (quote == '')
+ return subst(result, \, quot;);
+ else if (quote == '\'')
+ return subst(result,', apos;);
+ 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::pairbool, std::string 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
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{absolute path to/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
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_castint(val_/100)) '.'
- abs(static_castint(val_)%100) \\textwidth;
- break;
+ snprintf(buffer, 78, %.2f\\textwidth, val_/100.0);
+ break;
case PCW:
- buffer abs(static_castint(val_/100)) '.'
- abs(static_castint(val_)%100) \\columnwidth;
- break;
+ snprintf(buffer, 78, %.2f\\columnwidth, val_/100.0);
+ break;
case PPW:
- buffer abs(static_castint(val_/100)) '.'
- abs(static_castint(val_)%100) \\paperwidth;
- break;
+ snprintf(buffer, 78, %.2f\\paperwidth, val_/100.0);
+ break;
case PLW:
- buffer abs(static_castint(val_/100)) '.'
- abs(static_castint(val_)%100) \\linewidth;
- break;
+ snprintf(buffer, 78, %.2f\\linewidth, val_/100.0);
+ break;
case PPH:
- buffer abs(static_castint(val_/100)) '.'
- abs(static_castint(val_)%100) \\paperheight;
- break;
+ snprintf(buffer, 78, %.2f\\paperheight, val_/100.0);
+ break;
case PTH:
- buffer abs(static_castint(val_/100)) '.'
- abs(static_castint(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;
}
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: 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{absolute path to/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
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
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{mangled name}, 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{absolute path
to/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
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)
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 sstream
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_ptrSpecialisedMover 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 boost/noncopyable.hpp
#include boost/shared_ptr.hpp
#include map
#include string
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
* code
* sh $$s/move_fig.sh $$i $$o
* /code
* 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 bool
move(std::string const from,
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
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: [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 mediaobject
+* insetcite.[hC] (docbook, latex, cleanupWhitespace):
implementing
As here.
+DocBook output for this inset ( citationcontent/citation )
+
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. /Andreas Applied. -- 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 copypasted 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 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 ALT role=tex output
* graphic 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 - 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 - 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: !-- layout should of course have been a IDREF to the layouts actually -- !-- found in the different textclasses. Is that possible to -- !-- accomplish? (Lgb) -- 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] 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
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. :-)
[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
---
[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 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]
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"
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] 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
Angus Leeming <[EMAIL PROTECTED]> writes:
> You attached the insetcite patch...
That's what happens if you start posting before waking up ...
Sorry. /Andreas
Index: src/buffer.C === RCS file: /cvs/lyx/lyx-devel/src/buffer.C,v retrieving revision 1.584 diff -u -p -r1.584 buffer.C --- src/buffer.C2004/10/09 21:32:55 1.584 +++ src/buffer.C2004/10/21 07:35:00 @@ -1089,6 +1089,13 @@ void Buffer::makeDocBookFile(string cons ofs << " PUBLIC \"-//OASIS//DTD DocBook V4.2//EN\"";
string preamble = params().preamble;
+ if (runparams.flavor != OutputParams::XML ) {
+ preamble += "\n";
+ preamble += "\n";
+ preamble += "\n";
+ preamble += "\n";
+ }
+
string const name = runparams.nice ? ChangeExtension(pimpl_->filename, ".sgml")
: fname;
preamble += features.getIncludedFiles(name);
Index: src/insets/insetgraphics.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.258
diff -u -p -r1.258 insetgraphics.C
--- src/insets/insetgraphics.C 2004/10/05 13:38:31 1.258
+++ src/insets/insetgraphics.C 2004/10/21 07:35:13
@@ -295,22 +295,22 @@ string const InsetGraphics::createLatexO
// before writing it to the output stream.
ostringstream options;
if (!params().bb.empty())
- options << " bb=" << rtrim(params().bb) << ",\n";
+ options << " bb=" << rtrim(params().bb) << ",\n";
if (params().draft)
- options << " draft,\n";
+ options << " draft,\n";
if (params().clip)
- options << " clip,\n";
+ options << " clip,\n";
if (!float_equal(params().scale, 0.0, 0.05)) {
if (!float_equal(params().scale, 100.0, 0.05))
- options << " scale=" << params().scale / 100.0
+ options << " scale=" << params().scale / 100.0
<< ",\n";
} else {
if (!params().width.zero())
- options << " width=" << params().width.asLatexString() << ",\n";
+ options << " width=" << params().width.asLatexString() << ",\n";
if (!params().height.zero())
- options << " height=" << params().height.asLatexString() << ",\n";
+ options << " height=" << params().height.asLatexString() << ",\n";
if (params().keepAspectRatio)
- options << " keepaspectratio,\n";
+ options << " keepaspectratio,\n";
}
// Make sure rotation angle is not very close to zero;
@@ -341,50 +341,50 @@ string const InsetGraphics::createLatexO
string const InsetGraphics::toDocbookLength(LyXLength const & len) const
{
ostringstream result;
- switch (len.unit() ) {
- case LyXLength::SP: //< Scaled point (65536sp = 1pt) TeX's smallest unit.
+ switch (len.unit()) {
+ case LyXLength::SP: // Scaled point (65536sp = 1pt) TeX's smallest unit.
result << len.value() * 65536.0 * 72 / 72.27 << "pt";
break;
- 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";
break;
- case LyXLength::BP: //< Big point (72bp = 1in), also PostScript point
+ case LyXLength::BP: // Big point (72bp = 1in), also PostScript point
result << len.value() << "pt";
break;
- case LyXLength::DD: //< Didot point = 1/72 of a French inch, = 0.376mm
+ case LyXLength::DD: // Didot point = 1/72 of a French inch, = 0.376mm
result << len.value() * 0.376 << "mm";
break;
- case LyXLength::MM: //< Millimeter = 2.845pt
+ case LyXLength::MM: // Millimeter = 2.845pt
result << len.value() << "mm";
break;
- case LyXLength::PC: //< Pica = 12pt = 4.218mm
+ case LyXLength::PC: // Pica = 12pt = 4.218mm
result << len.value() << "pc";
break;
- case LyXLength::CC: //< Cicero = 12dd = 4.531mm
+ case LyXLength::CC: // Cicero = 12dd = 4.531mm
result << len.value() * 4.531 << "mm";
break;
- case LyXLength::CM: //< Centimeter = 10mm = 2.371pc
+ case LyXLength::CM: // Centimeter = 10mm = 2.371pc
result << len.value() << "cm";
break;
- case LyXLength::IN: //< Inch = 25.4mm = 72.27pt = 6.022pc
+ case LyXLength::IN: // Inch = 25.4mm = 72.27pt = 6.022pc
result << len.value() << "in";
break;
- case LyXLength::EX: //< Height of a small "x" for the current font.
+ case LyXLength::EX: //
Re: [PATCH] Docbook starsections
Andreas Vox <[EMAIL PROTECTED]> writes: > It's not so secret that I'd have to omit the subject line ... :-) /Andreas
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 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 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 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 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: 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
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: [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: 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 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 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.
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 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: 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
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: [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
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
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
[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] 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
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" == 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
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] 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: [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
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: 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
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: [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. :-)
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]
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: 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
