Menu
▾
▴
db2latex-devel — DB2LaTeX Developers' mailing list.
You can subscribe to this list here.
| 2003 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(13) |
May
(9) |
Jun
(7) |
Jul
(13) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(15) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Torsten B. <br...@ph...> - 2003-07-01 13:59:14
|
Halloechen! Vitaly Ostanin <vy...@vz...> writes: > I look into xsl/normalize-scape.mod.xsl. > > template name="scape" is really big... And will very big. > > I don't know another way for multiple parsing string (and > parsing result of parsing). > > What you think about creating xml file for symbols and > replacements? Such xml will easy contributed and maintained for > generating xslt from it. > > LaTeX doesn't support unicode characters by their numbers, so > each character need to be translated into valid latex. Do you mean something like <http://xml.coverpages.org/unicodeRahtz19981008.xml>? I think the best solution is an external tool. XSLT is not for everything. Especially because such a program is small, easy to be written in a portable way, and can substitute elegantly depending on context. Tschoe, Torsten. -- Torsten Bronger, aquisgrana, europa vetus |
|
From: Vitaly O. <vy...@vz...> - 2003-07-01 12:45:31
|
Hello, All! I look into xsl/normalize-scape.mod.xsl. template name="scape" is really big... And will very big. I don't know another way for multiple parsing string (and parsing result of parsing). What you think about creating xml file for symbols and replacements? Such xml will easy contributed and maintained for generating xslt from it. LaTeX doesn't support unicode characters by their numbers, so each character need to be translated into valid latex. -- Regards, Vyt mailto: vy...@vz... JID: vy...@vz... |
|
From: Vitaly O. <vy...@vz...> - 2003-07-01 11:30:56
|
On Mon, 30 Jun 2003 16:36:54 +0800 James Devenish <j-d...@us...> wrote: > In message <200...@vz...> > on Mon, Jun 30, 2003 at 10:57:03AM +0400, Vitaly Ostanin wrote: > > > I expect that we would actually keep a generated copy in > > > the CVS repository, > > > > For what? This way keep information twice and not synced :( > > It is quite common for projects to have a number of generated > files that are kept in CVS along with their source files. For a > start, this allows casual developers to avoid requiring > peculiar dependencies or extremely long bootstrap processes > when using the CVS files. Moreover, it provides the `diff` and > revision history advantages of CVS. Ok. Please, tell me - do you want to do syncronization with current DocBook l10n ? I have patch for l10n.xml for escaping l10n values to LaTeX valid text. But ru.xml is really old :(( -- Regards, Vyt mailto: vy...@vz... JID: vy...@vz... |
|
From: James D. <j-d...@us...> - 2003-06-30 08:37:02
|
In message <200...@vz...> on Mon, Jun 30, 2003 at 10:57:03AM +0400, Vitaly Ostanin wrote: > > I expect that we would actually keep a generated copy in the > > CVS repository, > > For what? This way keep information twice and not synced :( It is quite common for projects to have a number of generated files that are kept in CVS along with their source files. For a start, this allows casual developers to avoid requiring peculiar dependencies or extremely long bootstrap processes when using the CVS files. Moreover, it provides the `diff` and revision history advantages of CVS. |
|
From: Vitaly O. <vy...@vz...> - 2003-06-30 07:06:54
|
On Mon, 30 Jun 2003 07:56:01 +0800 James Devenish <j-d...@us...> wrote: > In message <3EF...@vz...> > on Sun, Jun 29, 2003 at 08:44:29PM +0400, Vitaly Ostanin wrote: > > Anyway, you can use XInclude for synchronization at build > > time, not in normal using. > > An interesting idea! > > > At preparing time for release this file must be parsed for > > inclusion and final output will used by release styles. > > I expect that we would actually keep a generated copy in the > CVS repository, For what? This way keep information twice and not synced :( > rather than only putting it into releases, but > I understand your sentiment. > > > For it I write xsl-style (attached) for parsing DocBook and > > DB2LaTeX localization files. See comments in style. > > Thanks, we will definitely look into this! I found bug, but it not affect current localization in DB2LaTeX. Fixed style is attached. > > Next, I copy DocBook l10n files to db2latex/xsl/common: > > l10n.dtd > > l10n.xsl > > l10n.xml > > Part of the reason I have not personally done any revamping of > the DB2LaTeX localisation is that we have modified those files > since our last sync with Norman's stylesheets. Please, give me an example. > Therefore, his are no longer drop-in replacements. Obviously > that is our problem, but it exists nevertheless. I don't see any problem. Attached style find any DB2LaTeX addons and keeps their in result output. If you not just add keys but modified their values, it's strange. <skipped/> -- Regards, Vyt mailto: vy...@vz... JID: vy...@vz... |
|
From: James D. <j-d...@us...> - 2003-06-29 23:56:10
|
In message <3EF...@vz...> on Sun, Jun 29, 2003 at 08:44:29PM +0400, Vitaly Ostanin wrote: > Anyway, you can use XInclude for synchronization at build time, > not in normal using. An interesting idea! > At preparing time for release this file must be parsed for > inclusion and final output will used by release styles. I expect that we would actually keep a generated copy in the CVS repository, rather than only putting it into releases, but I understand your sentiment. > For it I write xsl-style (attached) for parsing DocBook and > DB2LaTeX localization files. See comments in style. Thanks, we will definitely look into this! > Next, I copy DocBook l10n files to db2latex/xsl/common: > l10n.dtd > l10n.xsl > l10n.xml Part of the reason I have not personally done any revamping of the DB2LaTeX localisation is that we have modified those files since our last sync with Norman's stylesheets. Therefore, his are no longer drop-in replacements. Obviously that is our problem, but it exists nevertheless. > BTW, localization files in DocBook is generated too True. |
|
From: James D. <j-d...@us...> - 2003-06-28 05:10:08
|
In message <200...@vz...> on Fri, Jun 27, 2003 at 07:20:35PM +0400, Vitaly Ostanin wrote: > For example, what keys are not exists in Norman's stylesheets ? LaTeX-specific ones :) > Anyway, it's possible to import keys from Norman's styles > into your localization files. This can be done with XML > Inclusions [1]. With this schema manual synchronization not > needed. I understand that, but I don't think we should have XInclude Candidate support as a prerequisite for DB2LaTeX (even though it's fairly common these days). > I look into db2latex-xsl-0.7+20030622 snapshot: localization files in > xsl/common is not well-formed XML. It's normal ? Thanks for pointing this out. I would imagine that when the localisations are modernised, this will in time get corrected. Ramon will have to get back to you about it. Thanks for alerting us to these problems. |
|
From: Vitaly O. <vy...@vz...> - 2003-06-27 15:29:48
|
On Fri, 27 Jun 2003 07:53:04 +0800 James Devenish <j-d...@us...> wrote: > In message <200...@vz...> > on Thu, Jun 26, 2003 at 02:12:35PM +0400, Vitaly Ostanin wrote: > > I'm trying to use db2latex-0.7 for our documentation project > > (docs.altlinux.ru) > > I recommend using a more-recent DB2LaTeX version such as the > daily snapshots: <http://db2latex.sourceforge.net/snapshot>. > These snapshots contain a large number of fixes to make > DB2LaTeX work better with existing DocBook documents. Ok, thanks. <skipped/> > The DB2LaTeX localisation files contain more keys than Norman's > stylesheets. For example, what keys are not exists in Norman's stylesheets ? Anyway, it's possible to import keys from Norman's styles into your localization files. This can be done with XML Inclusions [1]. With this schema manual synchronization not needed. I look into db2latex-xsl-0.7+20030622 snapshot: localization files in xsl/common is not well-formed XML. It's normal ? Links: [1] http://www.w3.org/TR/xinclude/ <skipped/> -- Regards, Vyt mailto: vy...@vz... JID: vy...@vz... |
|
From: James D. <j-d...@us...> - 2003-06-26 23:53:13
|
In message <200...@vz...> on Thu, Jun 26, 2003 at 02:12:35PM +0400, Vitaly Ostanin wrote: > I'm trying to use db2latex-0.7 for our documentation project > (docs.altlinux.ru) I recommend using a more-recent DB2LaTeX version such as the daily snapshots: <http://db2latex.sourceforge.net/snapshot>. These snapshots contain a large number of fixes to make DB2LaTeX work better with existing DocBook documents. > Dir "xsl/common" contain localization files derived from original > DocBook stylesheets but it's unmaintained. Now original styles > is more localized for more languages. They are not exactly unmaintained, as we make changes to them on occasion. However, you would be correct is saying that they have not been recently synchronised with information from Norman Walsh's DocBook XSL stylesheets. Perhaps Ramon can look into that. Thanks for mentioning it. > Tools with support XML Catalogs: Sure. We use usually use xsltproc (and sometimes Xalan) with catalogue support. > 1. Dependence on DocBook xsl-styles > 2. Dependence on XML Catalogs support > > for correct localization ? The DB2LaTeX localisation files contain more keys than Norman's stylesheets. Thus, I think DB2LaTeX needs to use its own localisation files. |
|
From: Vitaly O. <vy...@vz...> - 2003-06-26 10:21:37
|
Hello. I'm trying to use db2latex-0.7 for our documentation project (docs.altlinux.ru) Dir "xsl/common" contain localization files derived from original DocBook stylesheets but it's unmaintained. Now original styles is more localized for more languages. db2latex styles can use original DocBook localization, using full URI's for l10n files. This scheme depends on XML Catalogs [1] setup and XML tools for processing it. Tools with support XML Catalogs: libxml2 http://xmlsoft.org XIncluder http://xincluder.sourceforge.net/ and more. Question: Do you want to add: 1. Dependence on DocBook xsl-styles 2. Dependence on XML Catalogs support for correct localization ? Links: [1] http://www.oasis-open.org/committees/entity/spec.html -- Regards, Vyt mailto: vy...@vz... JID: vy...@vz... |
|
From: Steinar B. <sb...@do...> - 2003-05-04 16:20:54
|
>>>>> James Devenish <j-d...@us...>:
> Huh? I thought you could just insert your graphics codes directly.
Nope. It's a dia[1] drawing. I generate the .mp (MetaPost input
files), and .mps (PostScript generated by MetaPost) files, with the
following GNU makefile rule:
%.mps: %.dia
dia --nosplash --export-to-format=mp $<
mpost $*.mp
mv $(*F).1 $*.mps
The .mp files are TeX, but I don't know if pdflatex has the neccessary
macros loaded. Do you know?
The .mps files are EPS, as far as I can tell, but EPS in a form that
pdflatex can digest. I'm told pdflatex cannot digest arbitrary EPS
files.
> Alternatively, you could do something like this:
> <mediaobject>
> <textobject>
> <phrase role="latex">\input{my.file}</phrase>
> </textobject>
> </mediaobject>
Thanx. But there's still the scaling issue. And, I guess, not
picking an <imageobject> found inside the <mediaobject>, instead of
the <textobject>...?
Why's the role on the <phrase> and not on the <textobject>?
- Steinar
PS as I've said earlier, this was just an idle thought, and not
something I need. The .mps files work fine with pdflatex. So please
don't spend time on it on my account. Of course, if you find this an
interesting TeX-hack, I'm happy to assist in any way I can. :-)
[1] Gnome graphical editor, http://www.lysator.liu.se/~alla/dia/
|
|
From: James D. <j-d...@us...> - 2003-05-04 11:36:50
|
In message <87f...@do...>
on Sun, May 04, 2003 at 10:30:41AM +0200, Steinar Bang wrote:
> That's a possibility, using XInclude with xsltproc, or DocBook
> XSLT file inclusion extensions with one of the Java XSLT engines,
> to include the actual text.
Huh? I thought you could just insert your graphics codes directly.
Alternatively, you could do something like this:
> > <mediaobject>
> > <textobject>
> > <phrase role="latex">\input{my.file}</phrase>
> > </textobject>
> > </mediaobject>
|
|
From: James D. <j-d...@us...> - 2003-05-04 11:36:39
|
In message <87i...@do...> on Sun, May 04, 2003 at 08:42:08AM +0200, Steinar Bang wrote: > If both width and depth are in place, only width is used in > \includegraphics. One day, on our way toward implementing imagedata for DocBook 2, this will get fixed. However, it still might not do what you want. <http://docbook.org/tdg/en/html/imagedata.html> says: "If scaling to fit is requested, the content area is scaled until either the content width is the same as the viewport width (and the content depth is less than or equal to the viewport depth) or the content depth is the same as the viewport depth (and the content width is less than or equal to the viewport width), whichever comes first. In other words, scaling to fit never causes anamorphic scaling, it simply scales the image as large as possible without overflowing the bounds of the viewport area." |
|
From: Steinar B. <sb...@do...> - 2003-05-04 08:30:48
|
>>>>> James Devenish <j-d...@us...>: > One option in the style of DocBook is to use a particular attribute > (e.g. 'role') to trigger specific template handling in your own > driver file. However, there may be an existing mechanism that you > can use. If you have <mediaobject> with no <imageobject>s but with > a <textobject> containing <phrase role="latex">, you can insert > actual LaTeX commands (untested): > <mediaobject> > <textobject> > <phrase role="latex">\your\latex\code</phrase> > </textobject> > </mediaobject> That's a possibility, using XInclude with xsltproc, or DocBook XSLT file inclusion extensions with one of the Java XSLT engines, to include the actual text. But that won't give us scaling, hm... I don't really _need_ it. I just thought it would be neat to include vector graphics in a way that's not tied to PDF output. But all I ever output from TeX is PDF or PS, so...:-) |
|
From: Steinar B. <sb...@do...> - 2003-05-04 06:42:16
|
>>>>> James Devenish <j-d...@us...>: > Are you missing scalefit="1"? Er, yes. So I was. Sorry. With a scalefit="1" attribute on the <imageobject>, either width or depth are used as \includegraphics command arguments. If both width and depth are in place, only width is used in \includegraphics. |
|
From: James D. <j-d...@us...> - 2003-05-04 02:33:28
|
In message <87s...@do...>
on Sun, May 04, 2003 at 12:39:56AM +0200, Steinar Bang wrote:
> Is it possible to use MetaPost input files directly in the LaTeX files
> resulting from using the db2latex XSLT style sheet?
Maybe...
> I guess that would require generating something different than
> \includegraphics?
One option in the style of DocBook is to use a particular attribute
(e.g. 'role') to trigger specific template handling in your own driver
file. However, there may be an existing mechanism that you can use.
If you have <mediaobject> with no <imageobject>s but with a <textobject>
containing <phrase role="latex">, you can insert actual LaTeX commands
(untested):
<mediaobject>
<textobject>
<phrase role="latex">\your\latex\code</phrase>
</textobject>
</mediaobject>
|
|
From: James D. <j-d...@us...> - 2003-05-04 02:10:36
|
In message <87v...@do...> on Sun, May 04, 2003 at 12:37:31AM +0200, Steinar Bang wrote: > Version: db2latex CVS update from earlier today > or width attributes aren't transferred to the resulting > \includegraphics command in the TeX files. You will need to supply a DocBook example. > Using the scale attribute works, though. Are you missing scalefit="1"? |
|
From: Steinar B. <sb...@do...> - 2003-05-03 22:43:09
|
Is it possible to use MetaPost input files directly in the LaTeX files resulting from using the db2latex XSLT style sheet? I guess that would require generating something different than \includegraphics? - Steinar |
|
From: Steinar B. <sb...@do...> - 2003-05-03 22:37:39
|
Version: db2latex CVS update from earlier today If I have <imageobject> elements for MetaPost PostScript files, depth or width attributes aren't transferred to the resulting \includegraphics command in the TeX files. Using the scale attribute works, though. - Steinar |
|
From: Steinar B. <sb...@do...> - 2003-04-29 20:08:51
|
>>>>> James Devenish <j-d...@us...>:
[snip!]
> I'm not sure about this one... I have implemented a workaround like
> the one you suggested, though.
It works well most of the time, but it doesn't seem to like #
characters in the verbatim elements:
! Illegal parameter number in definition of \reserved@a.
<to be read again>
l.302 {{\texttt{Some fixed# width text}
}} & {{Some normal text}} \tabularnew...
?
Here's the table that created the problem:
<informaltable>
<tgroup cols="2">
<tbody>
<row>
<entry><programlisting>Some fixed# width text</programlisting></entry>
<entry>Some normal text</entry>
</row>
<row>
<entry><screen>More fixed width text</screen></entry>
<entry>More normal text</entry>
</row>
</tbody>
</tgroup>
</informaltable>
|
|
From: Steinar B. <sb...@do...> - 2003-04-28 18:15:38
|
>>>>> James Devenish <j-d...@us...>: > DB2LaTeX does honour the width attribute (but depth support was > missing). It may be that nobody else uses depth? :-) I used it by mistake. I meant to use width, and when I figured out what I had done wrong, all images had already been scaled to a suitable size for printing, and I just let it be. |
|
From: James D. <j-d...@us...> - 2003-04-27 23:39:53
|
In message <874...@do...> on Sun, Apr 27, 2003 at 11:54:37PM +0200, Steinar Bang wrote: > I would like db2latex to make use of any depth and/or width attributes > found on <imageobject> elements, to do scaling on the included image. DB2LaTeX does honour the width attribute (but depth support was missing). |
|
From: James D. <j-d...@us...> - 2003-04-27 23:30:25
|
In message <87a...@do...> on Sun, Apr 27, 2003 at 11:38:51PM +0200, Steinar Bang wrote: > If I put <programlisting> or <screen> inside a table <entry>, I get > error messages like the one below: > > ! LaTeX Error: Something's wrong--perhaps a missing \item. Hi, this is a paragraph-/lr- mode issue. This also arises with list environments and our basic workaround is to force p-type or X-type columns. I had simply not realised that Verbatim also required this workaround. But there is an additional problem with verbatim environments...they won't work with tabularx (which DB2LaTeX uses in some circumstances). I'm not sure about this one... I have implemented a workaround like the one you suggested, though. |
|
From: Steinar B. <sb...@do...> - 2003-04-27 21:54:43
|
I would like db2latex to make use of any depth and/or width attributes
found on <imageobject> elements, to do scaling on the included image.
Some of my documents contain images that are shown full size in HTML,
but have been scaled down in PDF, eg.:
<mediaobject>
<imageobject role="html">
<imagedata fileref="img/test.png" format="PNG"/>
</imageobject>
<imageobject role="fo">
<imagedata fileref="img/test.png" format="PNG" depth="6cm" scalefit="1"/>
</imageobject>
</mediaobject>
The db2latex XSL style sheets does not make use of the depth and width
attributes of <imagedata>, so it isn't enough to make db2latex use the
fo <imageobject>.
I have to create an extra <imageobject> for use by db2latex, in each
<mediaobject>, eg.:
<mediaobject>
<imageobject role="html">
<imagedata fileref="img/test.png" format="PNG"/>
</imageobject>
<imageobject role="fo">
<imagedata fileref="img/test.png" format="PNG" depth="6cm" scalefit="1"/>
</imageobject>
<imageobject role="latex">
<imagedata scale="25" fileref="img/test.png" format="PNG"/>
</imageobject>
</mediaobject>
I also have to figure out a suitable scaling factor for each image,
by trial and error, instead of scaling the image to the expected
size.
- Steinar
|
|
From: Steinar B. <sb...@do...> - 2003-04-27 21:39:01
|
If I put <programlisting> or <screen> inside a table <entry>, I get
error messages like the one below:
! LaTeX Error: Something's wrong--perhaps a missing \item.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.282 \begin{Verbatim}[]
?
The reason seems to be that LaTeX doesn't like Verbatim environments
inside tabular enviroments.
The reason for the use of <screen> and <programlisting> in this case,
has been to ensure that the text has been rendered in a fixed width
font. So what I've done, is to add the following templates to my
db2latex local customization style sheet:
<xsl:template match="entry/screen">
\tt{<xsl:apply-templates/>}
</xsl:template>
<xsl:template match="entry/programlisting">
\tt{<xsl:apply-templates/>}
</xsl:template>
This will not solve the general case for <programlisting> or <screen>
inside <entry>, but it's perhaps better than having the LaTeX
processing stop?
A small table to reproduce this problem, can be found at the end of
this message.
- Steinar
---Table to make LaTeX croak
<informaltable>
<tgroup cols="2">
<tbody>
<row>
<entry><programlisting>Some fixed width text</programlisting></entry>
<entry>Some normal text</entry>
</row>
<row>
<entry><screen>More fixed width text</screen></entry>
<entry>More normal text</entry>
</row>
</tbody>
</tgroup>
</informaltable>
|
