Re: InsetScript Font Size
On 10/23/18 7:23 PM, Jean-Marc Lasgouttes wrote: > Le 18/10/2018 à 02:36, Richard Kimberly Heck a écrit : >> The font in superscripts and subscripts looks to me to be the same size >> as that of the normal text, when it ought to be smaller. I had a look >> into this, and I can't see where the font size is set. Help? (We set the >> font STYLE here, but where is that supposed to make a difference?) > > I would look at FontInfo::realSize() and how it is used (or not) in > GuiFontLoader. I believe I have tracked down the problem. When we calculate the row metrics in breakRow, the font isn't set properly. The TextMetrics at that point has the right font info, but it doesn't seem to be picked up when the FontIterator is created in breakRow. If I'm following the code right, the font in the FontIterator is set from displayFont, but that makes no use of the information about the font that's in the TextMetrics. Rather, it gets the font from the paragraph and the layout. Which is just the normal font, in this case. I'm afraid I have no idea how to fix this. Riki
Re: Patch test with several minor dialog alignment fixes
On 24/10/2018 13:36, Daniel wrote: On 24/10/2018 12:20, Daniel wrote: On 24/10/2018 11:40, Daniel wrote: On 23/10/2018 18:37, Daniel wrote: - There is something strange going on with the size of the Advanced Find and Replace Widget. When docked to the top (or docked to the top and then undocked) its minimum height is the minimum height it has when docked to the side. But since the box layout is switched from horizontal to vertical this makes no sense. And also when the widget is first called it is on the side and can be made rather narrow. But once it has been docked to the top and back to the side it cannot be as narrow any more since it is restricted to the minimum width as if it were docked to the top (or docked to the top and undocked). I noticed that the Code Preview Pane does not share this strange behaviour with the other panes. And I noticed that its implemented differs a bit. For example, GuiViewSource.cpp has a ViewSourceWidget::ViewSourceWidget(QWidget * parent) : QWidget(parent), document_(new QTextDocument(this)), highlighter_(new LaTeXHighlighter(document_)) while the other panes seem not to have this. Could something like that explain the difference? I am just poking around in the dark... Daniel
Re: Parentheses keys are reversed in Hebrew
On 10/26/18 12:09 PM, Guy Rutenberg wrote: > Hi, > > I've started working on a patch. I removed the parentheses reversing > code in TextMetrics.cpp and in Paragraph.cpp. Now what remains to do > is to update the lyx2lyx script. > > Just a quick question before I write the code: > 1. Is there a simple way to iterate over all the text lines in > document.body? document.body is just a list (array). So for line in document.body: do stuff... will work. But one usually needs to know the line number, so if you really want to iterate over all the lines, then something like: for i in range(len(document.body)): do something with document.body[i] or i = 0 while i < len(document.body): But then there's the fact that one often changes the length of document.body along the way. So what you often see is something like: i = 0 while True: and we take care somewhere to make sure we break out of this. > 2. Is there a simple way to get the current language for a line in > document.body? > I just want to avoid writing the same code twice if such logic already > exists. Not that I know. I believe that language changes are effective only within paragraphs. So it would be enough to find the beginning of the paragraph you are in, and then look for \lang commands since then. The get_containing_layout routine will find you the beginning of the paragraph. Indeed, you can do: start_of_par = get_containing_inset(document.body, i)[4] and that will give you the first 'real' line of this paragraph (after the paragraph params). Then something like: j = find_token_backwards(document.body, "\\lang"...) can be used to find the last language switch before where we are now, if such there is. As it stands, find_token_backwards needs doesn't accept enough arguments to make this really clean. It takes a "starting" position, which would presumably be i here, but not an 'ending' position, which would be j (probably j-1, actually, I'm not sure). That would be easy enough to add, though. I suspect that a "get_language_for_line" routine could be useful elsewhere, so feel free to add it to lyx2lyx_tools.py. Riki
Re: Parentheses keys are reversed in Hebrew
Hi, I've started working on a patch. I removed the parentheses reversing code in TextMetrics.cpp and in Paragraph.cpp. Now what remains to do is to update the lyx2lyx script. Just a quick question before I write the code: 1. Is there a simple way to iterate over all the text lines in document.body? 2. Is there a simple way to get the current language for a line in document.body? I just want to avoid writing the same code twice if such logic already exists. Overall, it doesn't see to complicated to solve. Thanks, Guy On Fri, 26 Oct 2018 at 10:37, Jürgen Spitzmüller wrote: > Am Montag, den 22.10.2018, 10:21 +0200 schrieb Jean-Marc Lasgouttes: > > > > Finally (this might be a question for Jürgen), is the handling of > > Hebrew > > still different from the handling of other RtL languages in this > > respect? > > Yes. > > > It should not IMO. > > Definitely not. That's the point of the ticket I linked to earlier. > > Jürgen > > > > > JMarc >
Re: Build LyX with MSVC 2017
On 26/10/2018 10:03, Kornel Benko wrote: Am Freitag, 26. Oktober 2018 07:58:21 CEST schrieb Daniel : C:\Qt\5.9.7\msvc2015\include\QtCore\qcompilerdetection.h1352 Error LNK2019 unresolved external symbol "public: class std::basic_string,class std::allocator > const __thiscall lyx::Messages::getIfFound(class std::basic_string,class std::allocator > const &)const " (?getIfFound@Messages@lyx@@QBE?BV?$basic_string@IU?$char_traits@I@std@@V? This is defined in src/support/Messages.cpp. Don't know why it is unresolved. The support dir is always handled, independent of using install. Kornel All I can say is that LYX_INSTALL makes the difference between night and day... Daniel
Re: Problems searching with format enabled
Am Freitag, 26. Oktober 2018 11:40:27 CEST schrieb Jean-Marc Lasgouttes
:
> Le 26/10/2018 à 11:28, Kornel Benko a écrit :
> > I have a BIG problem with regexes containing accented characters. The
> > reason is that
> > lyx handles regexes in MATH_MODE and changes all occurrences of say 'ä' to
> > \ddot{a}.
>
> Tomaso can you remind us what the benefit of suing math mode was? I
> suspect this is creating more issues than it solves.
>
> JMarc
>
Interestingly if, instead of of used regexp-mode, I try directly with
ERT, the regex works.
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: Problems searching with format enabled
Le 26/10/2018 à 11:28, Kornel Benko a écrit :
I have a BIG problem with regexes containing accented characters. The reason is
that
lyx handles regexes in MATH_MODE and changes all occurrences of say 'ä' to
\ddot{a}.
Tomaso can you remind us what the benefit of suing math mode was? I
suspect this is creating more issues than it solves.
JMarc
Re: Problems searching with format enabled
Am Freitag, 26. Oktober 2018 10:14:46 CEST schrieb Tommaso Cucinotta
:
> On 24/10/18 18:51, Kornel Benko wrote:
> > (Having a GUI for selection of which attribute to ignore or not would be
> > better, but designing and
> > programming such a dialog is not my strength)
> >
> > Opinions please.
>
> great job, Kornel, to tackle a rework of this code, thanks!
> Your proposal sounds sound, just a simple question: whether you managed to
> re-run the test cases in
> development/autotests, after your changes ?
I tried and failed. Then I tried some tests manually, and they worked.
After some fiddling with findadv-05, it looks like lyx is too slow. And in fact
using 'KD:50' made this test pass.
ATM I am concentrating on whether the findadv works in 'normal' situations.
I have a BIG problem with regexes containing accented characters. The reason is
that
lyx handles regexes in MATH_MODE and changes all occurrences of say 'ä' to
\ddot{a}.
So the input of [a-zä]+ results in
regexp{[a-z\ddot{a}]+endregexp{}}
and of course does not match the desired.
I failed to find out where this substitution is done.
FWIW, '\w' does not work either in this case, because it does not recognize
'ä' as a valid character. This is VERY ascii centric IMHO.
> Is this now all pushed to master? I'll need to have a try soon.
Yes, but the last one. Anyway, lyx.org is not available ATM, so no commit
possible.
But of course I will post a patch if desired.
> T.
Kornel
diff --git a/development/autotests/findadv-05-in.txt b/development/autotests/findadv-05-in.txt
index a3ea5e3..0fcf149 100644
--- a/development/autotests/findadv-05-in.txt
+++ b/development/autotests/findadv-05-in.txt
@@ -1,10 +1,11 @@
# Basic test for format-aware searching
#
Lang sk_SK.utf8
CO: findadv-05.ctrl
TestBegin test.lyx -dbg key,find > findadv-05.loga.txt 2>&1
+KD: 50
CN: Part 1
KK: foo \Cefoo foo\Ce foo\C\[Home]
KK: \Cs
KK: \CF
# Uncheck ignore format
signature.asc
Description: This is a digitally signed message part.
Re: Problems searching with format enabled
On 24/10/18 18:51, Kornel Benko wrote: (Having a GUI for selection of which attribute to ignore or not would be better, but designing and programming such a dialog is not my strength) Opinions please. great job, Kornel, to tackle a rework of this code, thanks! Your proposal sounds sound, just a simple question: whether you managed to re-run the test cases in development/autotests, after your changes ? Is this now all pushed to master? I'll need to have a try soon. T.
Re: Build LyX with MSVC 2017
Am Freitag, 26. Oktober 2018 07:58:21 CEST schrieb Daniel : > C:\Qt\5.9.7\msvc2015\include\QtCore\qcompilerdetection.h1352 > Error LNK2019 unresolved external symbol "public: class > std::basic_string int>,class std::allocator > const __thiscall > lyx::Messages::getIfFound(class std::basic_string std::char_traits,class std::allocator > const &)const " > (?getIfFound@Messages@lyx@@QBE?BV?$basic_string@IU?$char_traits@I@std@@V? This is defined in src/support/Messages.cpp. Don't know why it is unresolved. The support dir is always handled, independent of using install. Kornel signature.asc Description: This is a digitally signed message part.
Re: Parentheses keys are reversed in Hebrew
Am Montag, den 22.10.2018, 10:21 +0200 schrieb Jean-Marc Lasgouttes: > > Finally (this might be a question for Jürgen), is the handling of > Hebrew > still different from the handling of other RtL languages in this > respect? Yes. > It should not IMO. Definitely not. That's the point of the ticket I linked to earlier. Jürgen > > JMarc signature.asc Description: This is a digitally signed message part
