Am Sonntag, dem 06.04.2025 um 10:08 + schrieb Roland Schmitz:
> great to see progress. This is/was my longest running issue I ever
> filed 😀
Well, this was a rather challenging one.
But it's good to see you're still around!
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https:
Hi,
great to see progress. This is/was my longest running issue I ever filed 😀
Thanks
Roland
Am 4. April 2025 16:38:56 UTC schrieb LyX Ticket Tracker :
>#1624: Inserting Cross Reference without having a label (auto-lab
On Sun, Sep 22, 2024 at 05:18:40PM GMT, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 22.09.2024 um 11:50 +0200 schrieb Jürgen Spitzmüller:
> > Yes. No idea what the issue here is (as it only breaks with the
> > Spanish version).
>
> It's the "nohyper" option that is (only) used in the Spanish versi
Am Sonntag, dem 22.09.2024 um 11:50 +0200 schrieb Jürgen Spitzmüller:
> Yes. No idea what the issue here is (as it only breaks with the
> Spanish version).
It's the "nohyper" option that is (only) used in the Spanish version.
I'll change that.
--
Jürgen
signature.asc
Description: This is a di
les/es/Handouts/Tufte_Handout_pdf2
> (Failed)
Yes. No idea what the issue here is (as it only breaks with the Spanish
version).
Setting "Put fragile content out of moving arguments" solves it, but of
course not for the 2.3 exports. I worked around it for now by moving
the labels manually out
On Sat, Sep 21, 2024 at 09:31:40AM GMT, Juergen Spitzmueller wrote:
> commit d43e82a5a79e167c27140b609895ffdcd1ed8997
> Author: Juergen Spitzmueller
> Date: Sat Sep 21 11:30:08 2024 +0200
>
> Only \protect labels in \thanks notes
>
> See https://mar
Am Samstag, dem 10.08.2024 um 08:36 + schrieb Roland Schmitz:
> great to se "my oldest Ticket" getting closed 😁
Good to see you're still around.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Hi *,
great to se "my oldest Ticket" getting closed 😁
Thanks
Roland
Am 9. August 2024 15:42:21 UTC schrieb LyX Ticket Tracker :
>#1624: Inserting Cross Reference without having a label (auto-labels)
>--+
>
n LyX 2.4.0dev?
What would be a better way? Renaming? Showing as "Duplicate"? What
is your use case?
That the reference is marked as BROKEN when referenced from outside
of the Note seems right, or?
Daniel
Looking at how labels are used in notes and branches across 2.3.5 and
2.4.0dev, I ca
r way? Renaming? Showing as "Duplicate"? What
is your use case?
That the reference is marked as BROKEN when referenced from outside
of the Note seems right, or?
Daniel
Looking at how labels are used in notes and branches across 2.3.5 and
2.4.0dev, I can see that this can get complic
;? What
is your use case?
That the reference is marked as BROKEN when referenced from outside
of the Note seems right, or?
Daniel
Looking at how labels are used in notes and branches across 2.3.5 and
2.4.0dev, I can see that this can get complicated. The 2.3.5
behaviour (renaming) seems cleare
referenced from outside
of the Note seems right, or?
Daniel
Looking at how labels are used in notes and branches across 2.3.5 and
2.4.0dev, I can see that this can get complicated. The 2.3.5
behaviour (renaming) seems clearest to me (and a little pedantic).
Andrew
I have never used branche
seems right, or?
Daniel
Looking at how labels are used in notes and branches across 2.3.5 and
2.4.0dev, I can see that this can get complicated. The 2.3.5 behaviour
(renaming) seems clearest to me (and a little pedantic).
Andrew
I have never used branches, so pardon my ignorance. But isn&#x
ng to
do here. What is the exact issue with how it is in LyX 2.4.0dev? What
would be a better way? Renaming? Showing as "Duplicate"? What is your
use case?
That the reference is marked as BROKEN when referenced from outside of
the Note seems right, or?
Daniel
Looking at how lab
On 2022-05-24 23:53, Andrew Parsloe wrote:
(LyX 2.4.0-alpha3 on windows 10)
If I copy text containing a label (e.g. of an equation) and paste into a
(yellow) Note, the label is pasted unchanged. There is no warning
message about the label being changed to label-1. The label in the Note
can be
(LyX 2.4.0-alpha3 on windows 10)
If I copy text containing a label (e.g. of an equation) and paste into a
(yellow) Note, the label is pasted unchanged. There is no warning
message about the label being changed to label-1. The label in the Note
can be referenced from within the Note or from wit
On 4/9/21 11:12 AM, Scott Kostyshak wrote:
> On Fri, Apr 09, 2021 at 05:34:06PM +0300, Yuriy Skalko wrote:
>> Hi all,
>>
>> I'm working on a document with several branches that have many duplicated
>> labels. Now all these labels are shown in the Cross-reference di
On Fri, Apr 09, 2021 at 05:34:06PM +0300, Yuriy Skalko wrote:
> Hi all,
>
> I'm working on a document with several branches that have many duplicated
> labels. Now all these labels are shown in the Cross-reference dialog and it
> doesn't matter if a branch is active or no
Hi all,
I'm working on a document with several branches that have many
duplicated labels. Now all these labels are shown in the Cross-reference
dialog and it doesn't matter if a branch is active or not (duplicated
labels have "DUPLICATE:" prefix). It would be much mor
Thanks, this has been fixed already in master.
Jürgen
Paul A. Rubin schrieb am Mi., 24. Feb. 2021, 23:09:
> The attached screenshot shows the find/replace dialog in Alpha 3 (on
> Linux Mint, using Liv's packaged version). Note that the label "Replace"
> in the replace next button is mostly off
ly if it is in a non-outputting context
> > itself).
> > >
> > > This indeed corresponds to the behavior I was expecting.
> >
> > The problem is that I am not sure how to mark "real" broken refs in
> > that case (e.g., to labels in notes or commen
case I would expect it to be marked as broken.
> > > We can probably omit the mark if the ref is in the same non-
> > > outputting
> > > context (or generally if it is in a non-outputting context itself).
> >
> > This indeed corresponds to the behavior I was e
orresponds to the behavior I was expecting.
>
> The problem is that I am not sure how to mark "real" broken refs in
> that case (e.g., to labels in notes or comments).
As of 2330b4ce9ca7d references in non-outputting insets are never
marked broken (even if they are arguably broken).
text itself).
>
> This indeed corresponds to the behavior I was expecting.
The problem is that I am not sure how to mark "real" broken refs in
that case (e.g., to labels in notes or comments).
Jürgen
>
> Scott
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Fri, Oct 02, 2020 at 08:35:16AM +0200, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 01.10.2020, 17:21 -0400 schrieb Scott Kostyshak:
> > Starting with this commit, if a deactivated branch has a reference to
> > a label that's in the same branch,
> > the reference is marked as "BROKEN". See att
Am Donnerstag, den 01.10.2020, 17:21 -0400 schrieb Scott Kostyshak:
> Starting with this commit, if a deactivated branch has a reference to
> a label that's in the same branch,
> the reference is marked as "BROKEN". See attached.
Actually, the ref _is_ "Broken" as the target label is in a non-
out
On Mon, Dec 31, 2018 at 06:32:10PM +0100, Juergen Spitzmueller wrote:
> commit 1db5abbfbd38c8a709eefe63aea65e1297b7725e
> Author: Juergen Spitzmueller
> Date: Mon Dec 31 18:32:38 2018 +0100
>
> Mark labels in non-outputting insets as inactive.
>
> Fixes: #
On 7/7/20 1:09 PM, Jürgen Spitzmüller wrote:
> Am Dienstag, den 07.07.2020, 19:36 +0300 schrieb Yuval Deutscher:
>> I hereby agree that my contributions to LyX be licensed under the
>> General Public License, Version 2 or any later version.
> Thank you very much. Committed to master.
>
> Riki, this
Am Dienstag, den 07.07.2020, 19:36 +0300 schrieb Yuval Deutscher:
> I hereby agree that my contributions to LyX be licensed under the
> General Public License, Version 2 or any later version.
Thank you very much. Committed to master.
Riki, this is candidate for stable.
Jürgen
signature.asc
De
nt, please contact the sender and delete all copies.*
0001-Update-labels-and-tooltips-for-moderncv-layout.patch
Description: Binary data
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Samstag, den 04.07.2020, 22:03 +0300 schrieb Yuval Deutscher:
> Update the user-facing strings in modercv's layout according to the
> documentation of the cventry command in moderncv.
Thanks for this. Could you please re-send the patch as an attachment,
and also add a license agreement assuring
Update the user-facing strings in modercv's layout according to the
documentation of the cventry command in moderncv.
Signed-off-by: Yuval Deutscher
---
lib/layouts/moderncv.layout | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/layouts/moderncv.layout
Am Samstag, den 29.12.2018, 17:14 +0100 schrieb Jean-Marc Lasgouttes:
> Stylistic remarks:
>
> * Why does linfo need to be static here? Looks like a cut and paste
> issue.
Yes, a relict from the old code. It does not need to be static indeed.
Fixed.
> * Is it necessary to initialize references?
Le 29/12/2018 à 10:10, Juergen Spitzmueller a écrit :
commit 3ae6bff5389d61b8f471fa337d5a016a725cf7d5
Author: Juergen Spitzmueller
Date: Sat Dec 29 10:08:02 2018 +0100
Do not consider deleted labels in ambiguity check
-void Buffer::setInsetLabel(docstring const & label, InsetL
On 05/29/2017 04:28 PM, Scott Kostyshak wrote:
> On Mon, May 29, 2017 at 02:03:10PM -0400, Richard Heck wrote:
>> In 2.3.x, the font of a label in a section heading matches that of the
>> section heading (e.g., large and bold), which leads it to consume more
>> space than it did in 2.2.x, when it w
On Mon, May 29, 2017 at 02:03:10PM -0400, Richard Heck wrote:
> In 2.3.x, the font of a label in a section heading matches that of the
> section heading (e.g., large and bold), which leads it to consume more
> space than it did in 2.2.x, when it was just normal size. I would
> suggest that this be
In 2.3.x, the font of a label in a section heading matches that of the
section heading (e.g., large and bold), which leads it to consume more
space than it did in 2.2.x, when it was just normal size. I would
suggest that this be switched back.
Richard
labels
-+
Reporter: venik| Owner: vfr
Type: defect | Status: new
Priority: high | Milestone: 2.2.3
Component: changes | Version: 1.6.5
Severity: normal | Resolution:
Keywords: patch
I did not yet upgrade to 2.1 because it takes exceedingly long to start on my
MacBook Pro (Mavericks).
In the 2.1 version the issue seems to be solved.
On 10 Jul 2014, at 11:51 , LyX Ticket Tracker wrote:
> #9188: Labels and References Panel cannot cl
label, eq:Def[a], is
>> being output as:
>>
>> \label{eq:Def=5Ba=5D}
>>
>> So it looks as they certain characters are being escaped here.
>> Intentionally? The same happens with all other labels.
>
>
> This does look to be intentional. (I
x27;s not forgotten?
If you look at View> Source, you can see that the label, eq:Def[a], is
being output as:
\label{eq:Def=5Ba=5D}
So it looks as they certain characters are being escaped here.
Intentionally? The same happens with all other labels.
This does look to be int
; Source, you can see that the label, eq:Def[a], is
being output as:
\label{eq:Def=5Ba=5D}
So it looks as they certain characters are being escaped here.
Intentionally? The same happens with all other labels.
Richard
John Kennan wrote:
> When instant preview is on, an equation label with square brackets shows up
> as hex codes.
Confirmed as regression to 2.0.x. Please can you create bug and attach the file
there so it's not forgotten?
Pavel
When instant preview is on, an equation label with square brackets shows
up as hex codes.
John
--
John Kennan
Department of Economics
University of Wisconsin
Social Science Building
1180 Observatory Drive
Madison, WI 53706
Phone: 608-262-5393
Fax: 608-263-3876 or 608-262-2033
http://www.ssc
On 12/07/2012 09:10 AM, Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
2012/12/4 Jean-Marc Lasgouttes :
Or we could always insert them opened.
I would not object.
Jürgen
JMarc
I'll do that change in trunk if I hear no objections.
This looks like a good idea to me.
rh
Jürgen Spitzmüller wrote:
> 2012/12/4 Jean-Marc Lasgouttes :
> > Or we could always insert them opened.
>
> I would not object.
>
> Jürgen
>
> > JMarc
I'll do that change in trunk if I hear no objections.
Jürgen
On 12/15/2011 11:34 AM, Rob Oakes wrote:
Dear Developers,
I've been working on modifying the XHTML created by LyX to be more compliant
with HTML5. In the process, though, I've run into a couple of snags,
particularly with wrap floats and figure labels.
In way of experimentation, I
Dear Developers,
I've been working on modifying the XHTML created by LyX to be more compliant
with HTML5. In the process, though, I've run into a couple of snags,
particularly with wrap floats and figure labels.
In way of experimentation, I would like to use the tag for figures a
Abdelrazak Younes ha scritto:
What about the buffer().isInternal() or buffer().internal() method ?
Afterward, implementation may be changed as appropriate.
OK for the new buffer().isInternal() but this method should be used in
the same commit. I guess this is in TocBackend.cpp:
- buffer_-
Jean-Marc Lasgouttes wrote:
Le 28/08/2009 08:40, Abdelrazak Younes a écrit :
Vincent van Ravesteijn wrote:
Most of all, I don't like the randomness with which this is done. All
LFUNs handled in LyXFunc should relate to the documentBuffer(). Now
some LFUNs are corrected and others are not. At le
Tommaso Cucinotta wrote:
Vincent van Ravesteijn ha scritto:
The comment was about r31219. I really don't like that commit because:
1) I don't want to spoil the code with an infinite amount of
if (buffer().fileName().extension() == "internal")
Absolutely agree. At least, it should be "if (buff
Vincent van Ravesteijn ha scritto:
The comment was about r31219. I really don't like that commit because:
1) I don't want to spoil the code with an infinite amount of
if (buffer().fileName().extension() == "internal")
Absolutely agree. At least, it should be "if (buffer().isInternal())".
2) th
Le 28/08/2009 08:40, Abdelrazak Younes a écrit :
Vincent van Ravesteijn wrote:
Most of all, I don't like the randomness with which this is done. All
LFUNs handled in LyXFunc should relate to the documentBuffer(). Now
some LFUNs are corrected and others are not. At least the following
should all
Vincent van Ravesteijn wrote:
My guess is that you wanted to refer to the LyXView.{h,cpp} patch
which introduces
LyXView::documentBufferView()
where I actually violated the protocol, apologies.
Actually, I was probably mislead by a comment from Vincent, I thought
he was talking about thi
My guess is that you wanted to refer to the LyXView.{h,cpp} patch
which introduces
LyXView::documentBufferView()
where I actually violated the protocol, apologies.
Actually, I was probably mislead by a comment from Vincent, I thought
he was talking about this GuiRef patch.
The comment w
On 27/08/2009 23:07, Abdelrazak Younes wrote:
On 27/08/2009 22:08, Tommaso Cucinotta wrote:
On a related note, I just wanted to "complete" (but not commit) the
patch by:
-) renaming the LyXView::view() method to LyXView::currentBufferView()
[ or LyXView::selectedBufferView() might constitute
On 27/08/2009 22:08, Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
Tommaso Cucinotta wrote:
when clicking on a broken reference to label, the current reference
is shown as BROKEN: also in the GuiRef.cpp dialog, but when clicking
on it (i.e., confirming its value -- for example, becaus
Abdelrazak Younes ha scritto:
Tommaso Cucinotta wrote:
when clicking on a broken reference to label, the current reference
is shown as BROKEN: also in the GuiRef.cpp dialog, but when clicking
on it (i.e., confirming its value -- for example, because I'm going
Hello Tommaso,
Even if you are a
Tommaso Cucinotta wrote:
Hello,
when clicking on a broken reference to label, the current reference is
shown as BROKEN: also in the GuiRef.cpp dialog, but when clicking on
it (i.e., confirming its value -- for example, because I'm going to
add the label just a few seconds afterward), the "BRO
Hello,
when clicking on a broken reference to label, the current reference is
shown as BROKEN: also in the GuiRef.cpp dialog, but when clicking on it
(i.e., confirming its value -- for example, because I'm going to add the
label just a few seconds afterward), the "BROKEN: Ref: " label is
ente
Jürgen Spitzmüller wrote:
> > Hmm, that's the problem, the action that would lead to this bug is not
> > possible anymore.
>
> At least it is possible without your patch. What exactly doesn't work?
I verified the bug didn't come back with your commit, so I guess you can
commit this to branch as w
Vincent van Ravesteijn wrote:
> > However, your explanations strike me sensible. Just check the reported
> > undo bug doesn't come back.
> >
> >
>
> Hmm, that's the problem, the action that would lead to this bug is not
> possible anymore.
At least it is possible without your patch. What exactly
On Sun, Jul 26, 2009 at 10:21:47PM +0200, Vincent van Ravesteijn wrote:
>
As to the proposed patch, I'd like to hear the opinion of math users.
>>> After some further investigation I found out that the bug was introduced
>>> in changeset 10553: "Output \\ at the end of the last lin
As to the proposed patch, I'd like to hear the opinion of math users.
After some further investigation I found out that the bug was introduced
in changeset 10553: "Output \\ at the end of the last line if it is
empty (fixes bug 2067)". This is wrong, because outputting an extra "\\"
woul
Vincent van Ravesteijn wrote:
> > As to the proposed patch, I'd like to hear the opinion of math users.
>
> After some further investigation I found out that the bug was introduced
> in changeset 10553: "Output \\ at the end of the last line if it is
> empty (fixes bug 2067)". This is wrong, becaus
and the patch.
Index:
C:/Users/Vincent/OpenSource/LyX/svn-filename/src/mathed/InsetMathGrid.cpp
===
---
C:/Users/Vincent/OpenSource/LyX/svn-filename/src/mathed/InsetMathGrid.cpp
(revision 30748)
+++
C:/Users/Vincent/OpenSourc
As to the proposed patch, I'd like to hear the opinion of math users.
After some further investigation I found out that the bug was introduced
in changeset 10553: "Output \\ at the end of the last line if it is
empty (fixes bug 2067)". This is wrong, because outputting an extra "\\"
would mea
Uwe Stöhr wrote:
> > It looks like someone spent some effort not to output &'s if they are
> > not necessary.
André: http://www.lyx.org/trac/changeset/5004
> > Why would it be more correct to output all &'s ? Isn't it
> > much cleaner not to output them ?
>
> It is not clean and even wrong. That
Vincent van Ravesteijn schrieb:
Besides this, have a look at the LaTeX companion 2nd edition.
Ah, I always wondered what this LaTeX thing is you were all talking about.
This book is the best LaTeX book I know. You find there not only the usual LaTeX things but also
special solutions and des
Vincent van Ravesteijn wrote:
> > Besides this, have a look at the LaTeX companion 2nd edition.
>
> Ah, I always wondered what this LaTeX thing is you were all talking about.
And it isn't even friday :-)
Jürgen
Besides this, have a look at the LaTeX companion 2nd edition.
Ah, I always wondered what this LaTeX thing is you were all talking about.
Vincent
Vincent van Ravesteijn schrieb:
It looks like someone spent some effort not to output &'s if they are
not necessary. Why would it be more correct to output all &'s ? Isn't it
much cleaner not to output them ?
It is not clean and even wrong. That we not output the column separators causes the
Uwe Stöhr schreef:
> Is the attached ok ?
This only cures the symptom. The bug is that mathed doesn't output a
"&" for every column, no matter if the row is empty or not.
Create for example a multiline equation where the first row reads "a =
b = c", the second row is empty, and the third row
> Is the attached ok ?
This only cures the symptom. The bug is that mathed doesn't output a "&" for every column, no matter
if the row is empty or not.
Create for example a multiline equation where the first row reads "a = b = c", the second row is
empty, and the third row reads "x = y = z"
L
Is the attached ok ?
Vincent
Index: X:/lyx-devel/src/mathed/InsetMathGrid.cpp
===
--- X:/lyx-devel/src/mathed/InsetMathGrid.cpp (revision 30609)
+++ X:/lyx-devel/src/mathed/InsetMathGrid.cpp (working copy)
@@ -654,6 +654,9 @@
Michal Skrzypek wrote:
Dear LyX developers,
I have some question: I will soon need to write a paper in Polish,
but currently there is no way of having "Theorem", "Proposition" and
alike in Polish language other than translating layouts manually (or
have I missed something?). What is the
Dear LyX developers,
I have some question: I will soon need to write a paper in Polish,
but currently there is no way of having "Theorem", "Proposition" and
alike in Polish language other than translating layouts manually (or
have I missed something?). What is the best approach to this tas
hi,
labels and references in read-only documents seem no to work.
if you click on either on label or crosref dialog they appear
empty. this can be seen if you work with eg manuals if lyx
is properly installed (wont be seen on checkout-ed tree).
pavel
ability to make a label, because it will
still have some uses. But lots of labels could be automatic:
Writer wants to reference something
1. The writer bring up a list of all things that can be referenced.
2. The writer select an item, perhaps using that
"right-click->copy as r
On 2009-04-13, Vincent van Ravesteijn wrote:
>> Another solution would be a kind of "implicit" label, that doesn't
>> actually surface in LyX at all. Every section-type entity, and maybe
>> other things, too---figures, tables, etc---could have an "implicit"
>> label which would get generated w
rgheck writes:
> The labels can be output only if they're referenced. That might need
> some kind of double pass, but I'll bet the reference cache could be
> used for this purpose already.
I guess validate() can take care of that.
JMarc
are lots of problems any way you try to do this. And
I think you're right that the "invisible inset" approach won't work. So
we're back to the other idea: EVERY section, figure, etc, always has a
label associated with it, but this label won't be an inset; it'll
The label is just a piece of machinery I don't care about.
When I write a document, why should the list of labels be polluted
with labels I don't reference? This way writing a book would be
horror. But when the automatic labels don't appear in the list of
referable labels, then
e discussions.
When I write a document, why should the list of labels be polluted
with labels I don't reference?
>
We won't add labels you don't refer to. I thought I said " 'Insert
reference to section', that will insert a label and a reference at once."
I
to section", that will
> insert a label and a reference at once. Or one can think of a second
tab in the cross-reference
> dialog showing all sections too.
We've had this discussion several times the last years. Auto-labeling
is not useful.
... says Uwe...
When I write a docum
. Or one can think of a second tab in
the cross-reference
> dialog showing all sections too.
We've had this discussion several times the last years. Auto-labeling is not
useful.
When I write a document, why should the list of labels be polluted with labels I don't reference?
This way
a label ?
Maybe if it's not, we can add it? Duplicate labels aren't such a
problem, really.
Technically not, but if I have a document in which multiple labels point
to the same thing, I will get confused or I will make errors.
Another solution would be a kind of "implicit"
label doesn't have to
be in the section environment itself. Maybe if it's not, we can add it?
Duplicate labels aren't such a problem, really.
Another solution would be a kind of "implicit" label, that doesn't
actually surface in LyX at all. Every section-type entit
Vincent van Ravesteijn - TNW wrote:
I don't see any issue here, but I'd like to hear from Abdel.
I do.
thebuffer should maybe read the_buffer, and both thebuffer and num
should be constified.
I'm not sure what you mean about the first bit, but I did the second.
rh
-Original Message-
From: rgheck [mailto:[EMAIL PROTECTED]
Sent: dinsdag 28 oktober 2008 16:39
To: Abdelrazak Younes
Cc: Vincent van Ravesteijn - TNW; LyX Devel List
Subject: Re: Labels/Crossrefs problem
Abdelrazak Younes wrote:
> On 28/10/2008 14:51, rgheck wrote:
>> Vi
(in doc2)
then the labels in the cross-ref dialog are those from doc1.
This is solved by the attached patch.
We should not restore the last used buffer if the active buffer has
changed. Especially not when you cannot choose the buffer which is now
still the case.
I don't see any issue
On 28/10/2008 14:51, rgheck wrote:
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 14:55 +0200, Vincent van Ravesteijn wrote:
Hi all,
A. 1. create a new document (doc1),
2. insert a label,
3. insert a cross-ref
4. create a new document (doc2)
5. insert a cross-ref (in doc2)
then the labels
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 14:55 +0200, Vincent van Ravesteijn wrote:
Hi all,
A.
1. create a new document (doc1),
2. insert a label,
3. insert a cross-ref
4. create a new document (doc2)
5. insert a cross-ref (in doc2)
then the labels in the cross-ref dialog are
On Sat, 2008-10-25 at 14:55 +0200, Vincent van Ravesteijn wrote:
> Hi all,
>
> A.
> 1. create a new document (doc1),
> 2. insert a label,
> 3. insert a cross-ref
> 4. create a new document (doc2)
> 5. insert a cross-ref (in doc2)
> then the labels in the cross-ref
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 11:32 -0400, rgheck wrote:
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 11:12 -0400, rgheck wrote:
Why isn't red colored text being painted in a footnote ?
You want it to be?
Wel
On Sat, 2008-10-25 at 11:32 -0400, rgheck wrote:
> Vincent van Ravesteijn wrote:
> > On Sat, 2008-10-25 at 11:12 -0400, rgheck wrote:
> >
> >
> >>> Why isn't red colored text being painted in a footnote ?
> >>>
> >>>
> >>>
> >> You want it to be?
> >>
> >
> > Well, if I choose to
On 25/10/2008 16:57, Vincent van Ravesteijn wrote:
Why do we have the InsetFootLike class ?
History. Part of my black list... :-)
Why does InsetFootLike::draw do what it does ?
Same... the idea is (IIUC) that the font used is always fixed and
independent of the context around the
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 11:12 -0400, rgheck wrote:
Why isn't red colored text being painted in a footnote ?
You want it to be?
Well, if I choose to make text red (and in the LaTeX output it is), then
I expect it to be drawn with a nice red color
On Sat, 2008-10-25 at 11:12 -0400, rgheck wrote:
> > Why isn't red colored text being painted in a footnote ?
> >
> >
> You want it to be?
Well, if I choose to make text red (and in the LaTeX output it is), then
I expect it to be drawn with a nice red color on the screen.
> rh
>
Vincent
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 10:43 -0400, rgheck wrote:
Vincent van Ravesteijn wrote:
On Sat, 2008-10-25 at 16:18 +0200, Vincent van Ravesteijn wrote:
Hi all,
The list and section labels disappear in InsetCollapsables
Well, that is
1 - 100 of 381 matches
Mail list logo
