Re: [patch] support for \baselineskip
Le 08/04/2017 à 04:58, Uwe Stöhr a écrit : El 07.04.2017 a las 10:51, Jean-Marc Lasgouttes escribió: Maybe more like:... Thanks. The patch is now in including this hint and the new BLS unit is available for all lengths. Thanks. JMarc
Re: [patch] support for \baselineskip
El 07.04.2017 a las 13:30, Helge Hafting escribió: Do you want to have the BLS unit for all lengths, no matter if for vertical or horizontal? Yes, please. To be consistent with existing lengths/heights, and because it is useful sometimes. No need for artifical limitations. I put it in that way. So \baselineskip is now available for all lengths. Thank you for adding support for baselineskip. thanks. regards Uwe
Re: [patch] support for \baselineskip
El 07.04.2017 a las 10:51, Jean-Marc Lasgouttes escribió: Maybe more like:... Thanks. The patch is now in including this hint and the new BLS unit is available for all lengths. regards Uwe
Re: [patch] support for \baselineskip
Le 07/04/2017 à 02:03, Uwe Stöhr a écrit : OK, what about this?: Maybe more like: // baselineskip is approx. 1.2 times the font size for the cmr fonts // The value actually depends on the current paragraph (see TextMetrics::setRowHeight), but we do not have this information here. result = val_ * em_width * 1.2 / 100; JMarc
Re: [patch] support for \baselineskip
El 06.04.2017 a las 10:50, Jean-Marc Lasgouttes escribió: Concerning the code in Length::inInch: the value normally needs to take into account the line spacing setting of the document. I understand that it is difficult to obtain here, but a minimal action would be to document this shortcoming in the source until we can think of a good strategy. OK, what about this?: // baselineskip is approx. 1.2 times the font size for the cmr fonts // the exact value is defined in the document class and cannot obtained by LyX result = val_ * em_width * 1.2 / 100; thanks and regards Uwe
Re: [patch] support for \baselineskip
El 06.04.2017 a las 09:41, Jean-Marc Lasgouttes escribió: Le 06/04/2017 à 08:08, Pavel Sanda a écrit : I don't have strong opinion whether BLS should or shouldn't be available for both horizontal and vertical. I however dislike the code you posted. The easy way how to 'fix' it is to drop all these removeUnits on various places and thus effectively allow horizontal BLS as well. I thought about it again and in the past my opinion was that it is not LyX's task to tell the user what is sensible. So yes, a unit is a unit, it is up to the user to decide. if he wants e.g. to use BLS for the box frame separation we should not forbid it. So I opt to allow BLS for all lengths. regards Uwe
Re: [patch] support for \baselineskip
Le 02/04/2017 à 14:52, Uwe Stöhr a écrit :
After only 7 years ;-) I found time to finish a patch to support
\baselineskip, see attached. The patch is a fileformat change.
\baselineskip is the distance between the baseline of 2 subsequent text
lines in a paragraph. Therefore \vspace{\baselineskip} is a useful spacing.
Concerning the code in Length::inInch: the value normally needs to take
into account the line spacing setting of the document. I understand that
it is difficult to obtain here, but a minimal action would be to
document this shortcoming in the source until we can think of a good
strategy.
JMarc
Re: [patch] support for \baselineskip
Le 06/04/2017 à 08:08, Pavel Sanda a écrit : I don't have strong opinion whether BLS should or shouldn't be available for both horizontal and vertical. I however dislike the code you posted. The easy way how to 'fix' it is to drop all these removeUnits on various places and thus effectively allow horizontal BLS as well. The other and more painful way would be to write more generic code, where you distinguish vertXhoriz type of spacings and allow them only appropriate places _and_ use this distinction for all our defined spaces. I agree too that this length stuff is getting out of hand. After some time one has to stop a bit and think about it. JMarc
Re: [patch] support for \baselineskip
Uwe Stöhr wrote: >>> + // remove baselineskip from width units >>> + columnWidthUnitLC->removeUnit(Length::BLS); >>> + tabularWidthUnitLC->removeUnit(Length::BLS); >> >> This is ugly. >> >> Unless you want to be consistent and do it for all 'senseless' combinations >> of vert/horiz spacing used in opposite context drop these specific >> conditions spilled all over the place. > > I don't understand. Do you want to have the BLS unit for all lengths, no > matter if for vertical or horizontal? I asked for your opinion because I I don't have strong opinion whether BLS should or shouldn't be available for both horizontal and vertical. I however dislike the code you posted. The easy way how to 'fix' it is to drop all these removeUnits on various places and thus effectively allow horizontal BLS as well. The other and more painful way would be to write more generic code, where you distinguish vertXhoriz type of spacings and allow them only appropriate places _and_ use this distinction for all our defined spaces. Pavel
Re: [patch] support for \baselineskip
El 04.04.2017 a las 05:02, Pavel Sanda escribió: Uwe Stöhr wrote: revert = [ - [534, [revert_dashligatures]], + [535, [revert_baselineskip]], + [534, [revert_dashligatures, revert_baselineskip]], why is revert_baselineskip 2x? This was a mistake. I forgot to clean the file after my tests. + // remove baselineskip from width units + columnWidthUnitLC->removeUnit(Length::BLS); + tabularWidthUnitLC->removeUnit(Length::BLS); This is ugly. Unless you want to be consistent and do it for all 'senseless' combinations of vert/horiz spacing used in opposite context drop these specific conditions spilled all over the place. I don't understand. Do you want to have the BLS unit for all lengths, no matter if for vertical or horizontal? I asked for your opinion because I can live with both (only vertical or all). Jürgen once pointed out that BLS for horizontal lengths is senseless. Therefore I removed BLS for the lengths that are senseless. In the patch I forgot to handle the "senseless" lengths of the box dialog which I will add when I commit. So yes, I wanted to be consistent. thanks and regards Uwe
Re: [patch] support for \baselineskip
Uwe Stöhr wrote:
> revert = [
> - [534, [revert_dashligatures]],
> + [535, [revert_baselineskip]],
> + [534, [revert_dashligatures, revert_baselineskip]],
why is revert_baselineskip 2x?
> diff --git a/src/frontends/qt4/GuiGraphics.cpp
> b/src/frontends/qt4/GuiGraphics.cpp
> index 7e4f9ef37b..f05e2846cf 100644
> --- a/src/frontends/qt4/GuiGraphics.cpp
> +++ b/src/frontends/qt4/GuiGraphics.cpp
> @@ -152,6 +152,9 @@ GuiGraphics::GuiGraphics(GuiView & lv)
> connect(rotateOrderCB, SIGNAL(clicked()),
> this, SLOT(change_adaptor()));
>
> + // remove baselineskip from width units
> + widthUnit->removeUnit(Length::BLS);
> +
> filename->setValidator(new PathValidator(true, filename));
> setFocusProxy(filename);
>
> diff --git a/src/frontends/qt4/GuiHSpace.cpp b/src/frontends/qt4/GuiHSpace.cpp
> index ad829ecd81..4e7d995fcd 100644
> --- a/src/frontends/qt4/GuiHSpace.cpp
> +++ b/src/frontends/qt4/GuiHSpace.cpp
> @@ -92,6 +92,9 @@ GuiHSpace::GuiHSpace(bool math_mode, QWidget * parent)
> // initialize the length validator
> addCheckedWidget(valueLE, valueL);
> enableWidgets();
> +
> + // remove baselineskip from units
> + unitCO->removeUnit(Length::BLS);
> }
>
>
> diff --git a/src/frontends/qt4/GuiTabular.cpp
> b/src/frontends/qt4/GuiTabular.cpp
> index b021836ac0..4d5f683b38 100644
> --- a/src/frontends/qt4/GuiTabular.cpp
> +++ b/src/frontends/qt4/GuiTabular.cpp
> @@ -167,6 +167,10 @@ GuiTabular::GuiTabular(QWidget * parent)
> decimalPointED->setInputMask("X; ");
> decimalPointED->setMaxLength(1);
>
> + // remove baselineskip from width units
> + columnWidthUnitLC->removeUnit(Length::BLS);
> + tabularWidthUnitLC->removeUnit(Length::BLS);
> +
> // initialize the length validator
> addCheckedWidget(columnWidthED, columnWidthLA);
> addCheckedWidget(multirowOffsetED, multirowOffsetLA);
This is ugly.
Unless you want to be consistent and do it for all 'senseless' combinations of
vert/horiz spacing used in opposite context drop these specific conditions
spilled all over the place.
Pavel
Re: [patch] support for \\baselineskip
Am 28.10.2011 09:36, schrieb Jürgen Spitzmüller: You are right, that it is not in every case the exact value, but in, lets say, 90%. I think that the impossibility to get for all 100% the exact value should not prevent us from supporting \baselineskip. "90%" or "80%" or whatever is not the point. The point is that this is conceptually a different thing. Turning a relative value into an absolute is just not appropriate. This is true. But as you already said, getting the exact value is not always accessible. Not the value. Just look if baselineskip is used, and if so, use ERT instead of a LyX inset. OK, this should be possible. > Anyway, I think \baselineskip should not be > offered everywhere. I think it only makes sense in vertical dimensions. LaTeX allows this, so why should we don't support it. Maybe the user later on rotates some stuff in a box or so. Furthermore we already support sizes like "column width%" also for vertical dimensions, see the vspace inset. Following your argumentation, we should also not offer these there, but we do. We should not support all sorts of exotics (natively) just because "it's possible" and because there might be some corner case. I don't agree with you here. It is still the user's choice what to use. If there is some reason to use an exotic, but valid construct, we should not force him to use TeX code. A definition of what is exotic and what not is impossible. Take for example the unit "cc". This is a valid unit and you can create with it horizontal as well as vertical space. But tell me one LyX user who actually uses this unit. I don't know anybody. So I could say this is an exotic unit, so lets better not support it. The same is in my opinion for \baselineskip. regards Uwe
Re: [patch] support for \\baselineskip
Uwe Stöhr wrote: > > I don't understand. How can you find out the exact value of > > \baselineskip if > > the font size and linespread are defined in a class file? This is not > > possible. > > You are right, that it is not in every case the exact value, but in, lets > say, 90%. I think that the impossibility to get for all 100% the exact > value should not prevent us from supporting \baselineskip. "90%" or "80%" or whatever is not the point. The point is that this is conceptually a different thing. Turning a relative value into an absolute is just not appropriate. > >>> Why don't you revert to ERT and keep the \baselineskip value? > >> > >> This is impossible since you can use baselineskip in all insets and > >> settings with a length combo. Take for example the attached LyX file. > > > > Of course it is possible, You need to scan for the baselineskip value and > do > the appropriate conversion. > > But as you already said, getting the exact value is not always accessible. Not the value. Just look if baselineskip is used, and if so, use ERT instead of a LyX inset. > > Anyway, I think \baselineskip should not be > > offered everywhere. I think it only makes sense in vertical dimensions. > > LaTeX allows this, so why should we don't support it. Maybe the user later > on rotates some stuff in a box or so. Furthermore we already support sizes > like "column width%" also for vertical dimensions, see the vspace inset. > Following your argumentation, we should also not offer these there, but we > do. We should not support all sorts of exotics (natively) just because "it's possible" and because there might be some corner case. Jürgen
Re: [patch] support for \\\\baselineskip
Uwe Stöhr wrote: > >> I cannot agree to this. LyX is not there to tell the user what to use. > >> We should provide what LaTeX provides. We therefore already provide > >> vertical lengths for horizontal features. There is no reason why we > >> should not do the same for baselineskip. The users aren't stupid and > >> know what to choose. Moreover, having a box or image with a height of > >> 3\baselineskip is useful so why should we limit baselineskip to vspace > >> only? > > > > Because (1.) we obviously cannot implement it properly (with proper > > reversion), and so we have to stick to what is doable and (2) see below. > > OK. Can I give the patch into your hand and you implement \baselineskip as > you think it should be? I'm afraid I'm very short in time ATM. If I found some more time, I would finally address the multiple converters issue. > I think the user should decides where he want to use this length. If > he for some some strange reason prefers to have an image with a width > of 4\baselineskip, why should we forbid this? > >>> > >>> Because it's utter nonsense. > >> > >> As said above. The user is free to decide. > > > > As I user, I very much prefer a software that stops me from doing utter > > nonsense. I always adored LaTeX and LyX for exactly that. > > I still don't understand you here. LaTeX allows you to have an image width > of 4\baselineskip. If LaTeX allows you this, LyX should do this too. My point is similar to what Jean-Marc put forward with regard to the preferences. We should not add support for everything just because it's possible. Every option we add adds complexity to the GUI. A GUI application is very different to a macro-based/command line application here. In case of LaTeX, allowing \baselineskip for image width does not harm, because this does not get into the way of normal users. In case of LyX, it does, because the value is always in the combo. Modern GUI design takes this point very seriously. Look at Apple. They always decide for simplicity at the cost of mightiness. And obviously, people do appreciate that. Jürgen
Re: [patch] support for \\\\baselineskip
Am 26.07.2010 15:12, schrieb Jürgen Spitzmüller: Default is in almost all classes, except of the presentation classes, "10". Well, at least for the KOMA classes, it is "11". I'm sure there are many more variations if you go through the hundreds of classes available at CTAN. Thanks for the hint. So a proper reversion is indeed nearly impossible. regards Uwe
Re: [patch] support for \\\\baselineskip
Am 26.07.2010 15:06, schrieb Jürgen Spitzmüller: I cannot agree to this. LyX is not there to tell the user what to use. We should provide what LaTeX provides. We therefore already provide vertical lengths for horizontal features. There is no reason why we should not do the same for baselineskip. The users aren't stupid and know what to choose. Moreover, having a box or image with a height of 3\baselineskip is useful so why should we limit baselineskip to vspace only? Because (1.) we obviously cannot implement it properly (with proper reversion), and so we have to stick to what is doable and (2) see below. OK. Can I give the patch into your hand and you implement \baselineskip as you think it should be? I think the user should decides where he want to use this length. If he for some some strange reason prefers to have an image with a width of 4\baselineskip, why should we forbid this? Because it's utter nonsense. As said above. The user is free to decide. As I user, I very much prefer a software that stops me from doing utter nonsense. I always adored LaTeX and LyX for exactly that. I still don't understand you here. LaTeX allows you to have an image width of 4\baselineskip. If LaTeX allows you this, LyX should do this too. regards Uwe
Re: [patch] support for \\\\baselineskip
Uwe Stöhr wrote: > Default is in almost all classes, except of the presentation classes, "10". Well, at least for the KOMA classes, it is "11". I'm sure there are many more variations if you go through the hundreds of classes available at CTAN. Jürgen
Re: [patch] support for \\\\baselineskip
Uwe Stöhr wrote: > > Anyway, if you're too lazy to do this, I opt for limiting \baselineskip > > to vspace only (and maybe add other access points later). > > I cannot agree to this. LyX is not there to tell the user what to use. We > should provide what LaTeX provides. We therefore already provide vertical > lengths for horizontal features. There is no reason why we should not do > the same for baselineskip. The users aren't stupid and know what to > choose. Moreover, having a box or image with a height of 3\baselineskip is > useful so why should we limit baselineskip to vspace only? Because (1.) we obviously cannot implement it properly (with proper reversion), and so we have to stick to what is doable and (2) see below. > > I prefer having limited > > support over having a sloppy reversion. > > OK. When I don't have to write the lyx2lyx reversion routine alone, we can > revert it properly. You can do it in several steps. Implement it for vspace now, and implement it for other insets later, if you still think it is needed there. > >> I think the user should decides where he want to use this length. If he > >> for some some strange reason prefers to have an image with a width of > >> 4\baselineskip, why should we forbid this? > > > > Because it's utter nonsense. > > As said above. The user is free to decide. As I user, I very much prefer a software that stops me from doing utter nonsense. I always adored LaTeX and LyX for exactly that. Jürgen
Re: [patch] support for \\\\baselineskip
On 07/26/2010 08:56 AM, Uwe Stöhr wrote: Am 26.07.2010 14:45, schrieb Richard Heck: The class the defines the possible font sizes. You specify the font size in the document settings. But one option is "default", i.e., not to specify it. How do you know what that means? Default is in almost all classes, except of the presentation classes, "10". Usually, yes. I think Jurgen's main concern was that we not revert a length that is dependent upon the font size to one that is not dependent upon the font size. Anyway, I was thinking when looking at your IEEETran code that it would be nice to have a routine called "revertInsetToERT". I'm not sure precisely how to write it, but such a general routine would be useful. Richard
Re: [patch] support for \\\\baselineskip
Am 26.07.2010 14:45, schrieb Richard Heck: The class the defines the possible font sizes. You specify the font size in the document settings. But one option is "default", i.e., not to specify it. How do you know what that means? Default is in almost all classes, except of the presentation classes, "10". The problem is in my opinion not the lyx2lyx part. I only problems to look into BufferParam fontsize. But this is only my talentness. BufferParams::fontsize contains a string that contains the font size the user specified. It might be "default". Indeed, by default, it is "default". Thanks for the hint. So I only need to have a look at BufferParams::fontsize. regards Uwe
Re: [patch] support for \\\\baselineskip
Am 26.07.2010 08:02, schrieb Jürgen Spitzmüller: But all insets have different syntax. That would mean that I have to write a detection routine foe every inst. E.g. when I find baselineskip in a box I need to revert the whole box as TeX-code. This is a horror. I think this can be done. We have reversion routines for many insets at hand, so it's just a matter of effort. The work on the IEEETran reversion routines cost me 3 days and this task was much easier than this one. Anyway, if you're too lazy to do this, I opt for limiting \baselineskip to vspace only (and maybe add other access points later). I cannot agree to this. LyX is not there to tell the user what to use. We should provide what LaTeX provides. We therefore already provide vertical lengths for horizontal features. There is no reason why we should not do the same for baselineskip. The users aren't stupid and know what to choose. Moreover, having a box or image with a height of 3\baselineskip is useful so why should we limit baselineskip to vspace only? I prefer having limited support over having a sloppy reversion. OK. When I don't have to write the lyx2lyx reversion routine alone, we can revert it properly. I think the user should decides where he want to use this length. If he for some some strange reason prefers to have an image with a width of 4\baselineskip, why should we forbid this? Because it's utter nonsense. As said above. The user is free to decide. I'm off by now for about 2 weeks. regards Uw
Re: [patch] support for \\\\baselineskip
On 07/25/2010 08:55 PM, Uwe Stöhr wrote: Am 26.07.2010 00:32, schrieb Richard Heck: That's why I wrote in 90%. Usually you have single line space and nearly all document classes use 1.2 for the baselineskip then. I thought the worry was that there is no way to determine the fontsize. If it's default, which it is in most cases by far, then, as Jurgen said, you can't sensibly approximate \baselineskip because the font size and linespread are defined in the class file, not in LyX. The class the defines the possible font sizes. You specify the font size in the document settings. But one option is "default", i.e., not to specify it. How do you know what that means? The problem is in my opinion not the lyx2lyx part. I only problems to look into BufferParam fontsize. But this is only my talentness. BufferParams::fontsize contains a string that contains the font size the user specified. It might be "default". Indeed, by default, it is "default". Richard
Re: [patch] support for \\\\baselineskip
Uwe Stöhr wrote: > That's why I wrote in 90%. Usually you have single line space and nearly > all document classes use 1.2 for the baselineskip then. I don't know where you have that stats from. Anyway, reverting a dynamic value to a fixed one is the wrong way IMHO. > >> > Why don't you revert to ERT and keep the \baselineskip value? > >> > >> This is impossible since you can use baselineskip in all insets and > >> settings with a length combo. Take for example the attached LyX file. > > > > Of course it is possible, You need to scan for the baselineskip value > and do > the appropriate conversion. > > But all insets have different syntax. That would mean that I have to write > a detection routine foe every inst. E.g. when I find baselineskip in a > box I need to revert the whole box as TeX-code. This is a horror. I think this can be done. We have reversion routines for many insets at hand, so it's just a matter of effort. Anyway, if you're too lazy to do this, I opt for limiting \baselineskip to vspace only (and maybe add other access points later). I prefer having limited support over having a sloppy reversion. > What I can do is to check also for the set line spacing. baselineskip is > then > > baselineskip = fontsize * 1.2 * line spacing > > This is then correct for far over 90% of all cases. Again, no idea how you came to this statistics. > > Anyway, I think \baselineskip should not be > > > > offered everywhere. I think it only makes sense in vertical dimensions. > > I think the user should decides where he want to use this length. If he for > some some strange reason prefers to have an image with a width of > 4\baselineskip, why should we forbid this? Because it's utter nonsense. Jürgen
Re: [patch] support for \\\\baselineskip
Am 26.07.2010 00:32, schrieb Richard Heck: That's why I wrote in 90%. Usually you have single line space and nearly all document classes use 1.2 for the baselineskip then. I thought the worry was that there is no way to determine the fontsize. If it's default, which it is in most cases by far, then, as Jurgen said, you can't sensibly approximate \baselineskip because the font size and linespread are defined in the class file, not in LyX. The class the defines the possible font sizes. You specify the font size in the document settings. The problem is in my opinion not the lyx2lyx part. I only problems to look into BufferParam fontsize. But this is only my talentness. But all insets have different syntax. That would mean that I have to write a detection routine foe every inst. E.g. when I find baselineskip in a box I need to revert the whole box as TeX-code. This is a horror. Why do you need to revert the whole box? I'm not sure I understand this. What else should I do if the user sets e.g. a box height of 4\baselineskip? I think the user should decides where he want to use this length. If he for some some strange reason prefers to have an image with a width of 4\baselineskip, why should we forbid this? We don't forbid it. ERT would work perfectly well for that. But I'm not sure we want to offer every possibility for every case. It just confuses people. Why is this confusion? Users are already clever enough to understand that a box width of 13% text height is quite unuseful, although LyX offers this since ages. I'm now in holidays and leave it to you to decide what to do with my patch. regards Uwe
Re: [patch] support for \\\\baselineskip
On 07/25/2010 03:25 PM, Uwe Stöhr wrote: >> Its in ofer 90% the exact value in pt. So my reversion keeps the size the >> users wanted. > > I don't understand. How can you find out the exact value of \baselineskip if > the font size and linespread are defined in a class file? This is not > possible. That's why I wrote in 90%. Usually you have single line space and nearly all document classes use 1.2 for the baselineskip then. I thought the worry was that there is no way to determine the fontsize. If it's default, which it is in most cases by far, then, as Jurgen said, you can't sensibly approximate \baselineskip because the font size and linespread are defined in the class file, not in LyX. >> > Why don't you revert to ERT and keep the \baselineskip value? >> >> This is impossible since you can use baselineskip in all insets and >> settings with a length combo. Take for example the attached LyX file. > > Of course it is possible, You need to scan for the baselineskip value and do > the appropriate conversion. But all insets have different syntax. That would mean that I have to write a detection routine foe every inst. E.g. when I find baselineskip in a box I need to revert the whole box as TeX-code. This is a horror. Why do you need to revert the whole box? I'm not sure I understand this. In any event, my own view---I know I'm in the minority here---is that we do our best with new features and don't worry so much about reverting perfectly. I don't know why anyone would expect a file exported from 2.0 to 1.4.0 to compile the same, and I don't actually think anyone would. > Anyway, I think \baselineskip should not be offered everywhere. I think it only makes sense in vertical dimensions. I think the user should decides where he want to use this length. If he for some some strange reason prefers to have an image with a width of 4\baselineskip, why should we forbid this? We don't forbid it. ERT would work perfectly well for that. But I'm not sure we want to offer every possibility for every case. It just confuses people. rh
Re: [patch] support for \\\\baselineskip
>> Its in ofer 90% the exact value in pt. So my reversion keeps the size the >> users wanted. > > I don't understand. How can you find out the exact value of \baselineskip if > the font size and linespread are defined in a class file? This is not > possible. That's why I wrote in 90%. Usually you have single line space and nearly all document classes use 1.2 for the baselineskip then. >> > Why don't you revert to ERT and keep the \baselineskip value? >> >> This is impossible since you can use baselineskip in all insets and >> settings with a length combo. Take for example the attached LyX file. > > Of course it is possible, You need to scan for the baselineskip value and do > the appropriate conversion. But all insets have different syntax. That would mean that I have to write a detection routine foe every inst. E.g. when I find baselineskip in a box I need to revert the whole box as TeX-code. This is a horror. What I can do is to check also for the set line spacing. baselineskip is then baselineskip = fontsize * 1.2 * line spacing This is then correct for far over 90% of all cases. > Anyway, I think \baselineskip should not be > offered everywhere. I think it only makes sense in vertical dimensions. I think the user should decides where he want to use this length. If he for some some strange reason prefers to have an image with a width of 4\baselineskip, why should we forbid this? regards Uwe
Re: [patch] support for \\baselineskip
Uwe Stöhr wrote: > > I don't think it's feasible to revert to some pt value. > > Its in ofer 90% the exact value in pt. So my reversion keeps the size the > users wanted. I don't understand. How can you find out the exact value of \baselineskip if the font size and linespread are defined in a class file? This is not possible. > > Why don't you revert to ERT and keep the \baselineskip value? > > This is impossible since you can use baselineskip in all insets and > settings with a length combo. Take for example the attached LyX file. Of course it is possible, You need to scan for the baselineskip value and do the appropriate conversion. Anyway, I think \baselineskip should not be offered everywhere. I think it only makes sense in vertical dimensions. Jürgen
Re: [patch] support for \\baselineskip
Am 25.07.2010 16:17, schrieb Jürgen Spitzmüller: In my patch I failed to look in Length.cpp what is the current fontsize. Calling bv.buffer().params().fontsize doesn't work. Can you please help me here? All other things work as they should. No idea either. Too bad. I only want to have a look at the BufferParam "fontsize". This must be trivial to achieve but I'm too untalented to find out how. Any others who can help me? There was also a bug in the lyx2lyx routine. Better patch attached. I don't think it's feasible to revert to some pt value. Its in ofer 90% the exact value in pt. So my reversion keeps the size the users wanted. Why don't you revert to ERT and keep the \baselineskip value? This is impossible since you can use baselineskip in all insets and settings with a length combo. Take for example the attached LyX file. regards Uwe Neues_Dokument7.lyx Description: application/lyx
Re: [patch] support for \\baselineskip
Uwe Stöhr wrote: > > In my patch I failed to look in Length.cpp what is the current fontsize. > > Calling bv.buffer().params().fontsize doesn't work. Can you please help > > me here? All other things work as they should. No idea either. > There was also a bug in the lyx2lyx routine. Better patch attached. I don't think it's feasible to revert to some pt value. Why don't you revert to ERT and keep the \baselineskip value? Apart from that, it looks good. Jürgen
Re: [patch] support for \\baselineskip
Am 25.07.2010 05:57, schrieb Uwe Stöhr:
In my patch I failed to look in Length.cpp what is the current fontsize. Calling
bv.buffer().params().fontsize doesn't work. Can you please help me here? All
other things work as
they should.
There was also a bug in the lyx2lyx routine. Better patch attached.
regards Uwe
Index: lib/lyx2lyx/lyx_2_0.py
===
--- lib/lyx2lyx/lyx_2_0.py (revision 35011)
+++ lib/lyx2lyx/lyx_2_0.py (working copy)
@@ -2057,6 +2057,48 @@
i += 1
+def revert_baselineskip(document):
+" Revert baselineskips to corresponding value in pt "
+i = 0
+end = len(document.body) - 1
+star = ''
+quote = ''
+p = find_token(document.header, '\\paperfontsize', 0)
+if p != -1:
+ if document.header[p].find("default") != -1:
+fontsize = "10"
+ else:
+r = document.header[p].rfind(" ")
+fontsize = document.header[p][r:]
+while True:
+ k = document.body[i].find("baselineskip%")
+ if k != -1:
+# check if there is a star
+if document.body[i].rfind("*") != -1:
+ star = "*"
+# check if there is a "
+if document.body[i].rfind('"') != -1:
+ quote = '"'
+# find the last space
+j = document.body[i].rfind(" ")
+value = document.body[i][j:]
+# we now have 'xyyybaselineskip%zx'
+m = value.rfind("b")
+value = value[:m]
+# we now have 'xyyy' where x can be a " character
+if value.find('"') != -1:
+ value = value[2:]
+# 1\baselineskip = 1.2 * font size
+new_value = float(value) / 100 * 1.2 * float(fontsize)
+string = document.body[i][:j + 1] + quote + str(new_value) + "pt" + star + quote
+document.body[i] = string
+ if i == end:
+break
+ i += 1
+ star = ''
+ quote = ''
+
+
##
# Conversion hub
#
@@ -2117,7 +2159,7 @@
[398, []]
]
-revert = [[397, [revert_mathrsfs]],
+revert = [[397, [revert_baselineskip, revert_mathrsfs]],
[396, []],
[395, [revert_nameref]],
[394, [revert_DIN_C_pagesizes]],
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 35011)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -393,7 +393,8 @@
case Length::PPW: // Percent of PageWidth
case Length::PLW: // Percent of LineWidth
case Length::PTH: // Percent of TextHeight
- case Length::PPH: // Percent of Paper
+ case Length::PPH: // Percent of PaperHeight
+ case Length::BLS: // Percent of BaselineSkip
// Sigh, this will go wrong.
result << len.value() << "%";
break;
Index: src/Length.cpp
===
--- src/Length.cpp (revision 35012)
+++ src/Length.cpp (working copy)
@@ -15,9 +15,11 @@
#include
+#include "BufferView.h"
#include "Length.h"
#include "LyXRC.h"
+#include "support/convert.h"
#include "support/docstream.h"
#include
@@ -102,6 +104,9 @@
case PPH:
os << val_ / 100.0 << "\\paperheight";
break;
+ case BLS:
+ os << val_ / 100.0 << "\\baselineskip";
+ break;
default:
os << val_ << unit_name[unit_];
break;
@@ -140,6 +145,7 @@
case PCW:
case PTH:
case PPH:
+ case BLS:
// what it's a percentage of probably won't make sense for HTML,
// so we'll assume people have chosen these appropriately
os << val_ << '%';
@@ -204,6 +210,10 @@
// but this estimate might not be more accurate as the screen font
// is different then the latex font.
+ // current font size
+ //BufferView const & bv;
+ //double font_size = convert(bv.buffer().params().fontsize);
+
// Pixel values are scaled so that the ratio
// between lengths and font sizes on the screen
// is the same as on paper.
@@ -283,6 +293,11 @@
case Length::PPH:
result = val_ * text_width * 2.2 / 100;
break;
+ case Length::BLS:
+ // baselineskip is approx. 1.2 times the font size for the cmr fonts
+ // replace em_width with font_size!
+ result = val_ * em_width * 1.2 / 100;
+ break;
case Length::UNIT_NONE:
result = 0; // this cannot happen
break;
Index: src/Length.h
===
--- src/Length.h (revision 35011)
+++ src/Length.h (working copy)
@@ -20,6 +20,8 @@
namespace lyx {
+class BufferView;
+
// Solaris/x86 version 9 and earlier define these
#undef PC
#undef SP
@@ -56,6 +58,7 @@
PLW, //< Percent of LineWidth
PTH, //< Percent of TextHeight // Herbert 2002-05-16
PPH, //< Percent of PaperHeight // Herbert 2002-05-16
+ BLS, //< Percent of BaselineSkip// uwestoehr 2010-07-25
UNIT_NONE ///< no unit
};
Index: src/lengthcommon.cpp
===
--- src/lengthcommon.cpp (revision 35011)
+++ src/lengthcommon.cpp (working
Re: [patch] support for \\baselineskip
> IMHO \baselineskip is a very useful unit, I use it frequently. However, I
> think we should put baselineskip rather to the unit combo and make it
> accessible via "custom" vspace. Often, one needs a value such as
> \vspace{3\baselineskip} or even \vspace{0.5\baselineskip}.
Good idea. Attached is the patch that implements this.
In my patch I failed to look in Length.cpp what is the current fontsize. Calling
bv.buffer().params().fontsize doesn't work. Can you please help me here? All other things work as
they should.
thanks and regards
Uwe
Index: lib/lyx2lyx/lyx_2_0.py
===
--- lib/lyx2lyx/lyx_2_0.py (revision 35011)
+++ lib/lyx2lyx/lyx_2_0.py (working copy)
@@ -2057,6 +2057,44 @@
i += 1
+def revert_baselineskip(document):
+" Revert baselineskips to corresponding value in pt "
+i = 0
+end = len(document.body) - 1
+star = ''
+quote = ''
+p = find_token(document.header, '\\paperfontsize', 0)
+if p != -1:
+ fontsize = document.header[p][15:]
+while True:
+ k = document.body[i].find("baselineskip%")
+ if k != -1:
+# check if there is a star
+if document.body[i].rfind("*") != -1:
+ star = "*"
+# check if there is a "
+if document.body[i].rfind('"') != -1:
+ quote = '"'
+# find the last space
+j = document.body[i].rfind(" ")
+value = document.body[i][j:]
+# we now have 'xyyybaselineskip%zx'
+m = value.rfind("b")
+value = value[:m]
+# we now have 'xyyy' where x can be a " character
+if value.find('"') != -1:
+ value = value[2:]
+# 1\baselineskip = 1.2 * font size
+new_value = float(value) / 100 * 1.2 * float(fontsize)
+string = document.body[i][:j + 1] + quote + str(new_value) + "pt" + star + quote
+document.body[i] = string
+ if i == end:
+break
+ i += 1
+ star = ''
+ quote = ''
+
+
##
# Conversion hub
#
@@ -2117,7 +2155,7 @@
[398, []]
]
-revert = [[397, [revert_mathrsfs]],
+revert = [[397, [revert_baselineskip, revert_mathrsfs]],
[396, []],
[395, [revert_nameref]],
[394, [revert_DIN_C_pagesizes]],
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 35011)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -393,7 +393,8 @@
case Length::PPW: // Percent of PageWidth
case Length::PLW: // Percent of LineWidth
case Length::PTH: // Percent of TextHeight
- case Length::PPH: // Percent of Paper
+ case Length::PPH: // Percent of PaperHeight
+ case Length::BLS: // Percent of BaselineSkip
// Sigh, this will go wrong.
result << len.value() << "%";
break;
Index: src/Length.cpp
===
--- src/Length.cpp (revision 35012)
+++ src/Length.cpp (working copy)
@@ -15,9 +15,11 @@
#include
+#include "BufferView.h"
#include "Length.h"
#include "LyXRC.h"
+#include "support/convert.h"
#include "support/docstream.h"
#include
@@ -102,6 +104,9 @@
case PPH:
os << val_ / 100.0 << "\\paperheight";
break;
+ case BLS:
+ os << val_ / 100.0 << "\\baselineskip";
+ break;
default:
os << val_ << unit_name[unit_];
break;
@@ -140,6 +145,7 @@
case PCW:
case PTH:
case PPH:
+ case BLS:
// what it's a percentage of probably won't make sense for HTML,
// so we'll assume people have chosen these appropriately
os << val_ << '%';
@@ -204,6 +210,10 @@
// but this estimate might not be more accurate as the screen font
// is different then the latex font.
+ // current font size
+ //BufferView const & bv;
+ //double font_size = convert(bv.buffer().params().fontsize);
+
// Pixel values are scaled so that the ratio
// between lengths and font sizes on the screen
// is the same as on paper.
@@ -283,6 +293,11 @@
case Length::PPH:
result = val_ * text_width * 2.2 / 100;
break;
+ case Length::BLS:
+ // baselineskip is approx. 1.2 times the font size for the cmr fonts
+ // replace em_width with font_size!
+ result = val_ * em_width * 1.2 / 100;
+ break;
case Length::UNIT_NONE:
result = 0; // this cannot happen
break;
Index: src/Length.h
===
--- src/Length.h (revision 35011)
+++ src/Length.h (working copy)
@@ -20,6 +20,8 @@
namespace lyx {
+class BufferView;
+
// Solaris/x86 version 9 and earlier define these
#undef PC
#undef SP
@@ -56,6 +58,7 @@
PLW, //< Percent of LineWidth
PTH, //< Percent of TextHeight // Herbert 2002-05-16
PPH, //< Percent of PaperHeight // Herbert 2002-05-16
+ BLS, //< Percent of BaselineSkip// uwestoehr 2010-07-25
UNIT_NONE ///< no unit
};
Index: src/lengthcommon.cpp
===
Re: [patch] support for \baselineskip
Uwe Stöhr wrote:
> The attached simple patch adds \baselineskip as length for \vspace.
>
> \baselineskip is exactly the distance between two baselines of consecutive
> text lines. If the line spacing is default, \bigskip is equal to
> \baselineskip. If not one needs \baselineskip as length to get the space
> between lines. \baselineskip only makes sense for \vspace.
>
> I'm not really sure if we want support for this length and therefore did
> not add this as length for the paragraph separation in the document
> settings.
>
> Jürgen, JMarc and other LaTeX experts, what do you think? Should I proceed?
IMHO \baselineskip is a very useful unit, I use it frequently. However, I
think we should put baselineskip rather to the unit combo and make it
accessible via "custom" vspace. Often, one needs a value such as
\vspace{3\baselineskip} or even \vspace{0.5\baselineskip}.
Jürgen
