Jean-Marc Lasgouttes wrote:
> > Your diagnosis and suggested fix are right. IIRC we decided with JMarc
> > it was not worth going recursively into insets for toc purpose in
> > order to avoid potential visual problems (like big math insets or
> > branch, etc). So maybe we should add something betwe
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Your diagnosis and suggested fix are right. IIRC we decided with JMarc
> it was not worth going recursively into insets for toc purpose in
> order to avoid potential visual problems (like big math insets or
> branch, etc). So maybe we should add somet
On 13/10/2008 10:02, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Your diagnosis and suggested fix are right.
What would be the suggested fix?
asString(AS_STR_INSETS)
or
asString(AS_STR_LABEL | AS_STR_INSETS)
IOW does the TOC need AS_STR_LABEL?
Yes, that gives the numbe
Abdelrazak Younes wrote:
> Your diagnosis and suggested fix are right.
What would be the suggested fix?
asString(AS_STR_INSETS)
or
asString(AS_STR_LABEL | AS_STR_INSETS)
IOW does the TOC need AS_STR_LABEL?
I remember I have tried the latter and then the output was only correct in
some cases (
On 13/10/2008 08:20, Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
Export to plaintext does not produce a dash
at all in the TOC.
Seems that textString is currently broken in general (the same happens for
other special characters and for spaces at least).
It has to do
Jürgen Spitzmüller wrote:
> > Export to plaintext does not produce a dash
> > at all in the TOC.
>
> Seems that textString is currently broken in general (the same happens for
> other special characters and for spaces at least).
It has to do with TocBackend::updateItem passing asString(AS_STR_LABE
Jan Engelhardt wrote:
> Using a nonbreakdash in a header screws up its entry in the TOC when
> exported to pdflatex or DVI.
fixed.
> Export to plaintext does not produce a dash
> at all in the TOC.
Seems that textString is currently broken in general (the same happens for
other special charact
