Re: integral upper limit adjacent to integral sign
On Wed, Feb 07, 2018 at 10:56:58AM +, Enrico Forestieri wrote: > On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote: > > On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote: > > > > > Enrico, for reference this is the commit where we use > > > QFontMetrics::width in some cases instead of the QTextLayout thing. > > > > > > I tried to revert it and did not see much difference. > > > > I tried a vanilla "git revert" on master and there was a conflict so I > > did not look further. If you have a patch that reverts it, I could test > > that. > > Please, try the attached. Works well for me. Scott signature.asc Description: PGP signature
Re: [patch] Chapter top spacing - regression
On 02/07/2018 05:00 PM, Pavel Sanda wrote: > Hi, > > I already wrote about this some time ago, switching to 2.3 made going through > the documents with chapters somewhat annoying on small screens because third > of > my monitor is taken by vertical space. Eg. after loading tutorial on my laptop > I can't read even the first paragraph because of the empty space. > > This was not the case with 2.0 as you can see in attached screenshot > (little blurry due to high compression). > > Left-most lyx 2.0, middle lyx 2.3, right lyx 2.3 with the attached patch. > I look at git history and the change was not caused by the layout file, > so my speculation is that some painting routines changed. > Anyway I propose to change the layout file as it seems most straightfoward. > > Opinions? No objection, but I agree that there must be some underlying cause. I'll guess that maybe the size of the Chapter font is now being used to calculate what "4" means, whereas maybe it was the size of the base font previously? Richard > > Pavel
Re: [Patch] Unify groups LFUN (was: [LyX/master] Add missing break and polish formatting)
Pavel Sanda wrote: > Jean-Marc Lasgouttes wrote: > >>> Here is what I had in mind. Works quite well. > >> Who would have guessed what the innocent commit of such esoteric lfun > >> would trigger :) > > > > It is still small activity :) Does it work for you? > > Will try tomorrow. Your patch works here. Pavel
Re: [Patch] Unify groups LFUN
Jean-Marc Lasgouttes wrote: >> This is what I come up with, if (!from.nextInset()) line is taken from >> inset-forall but I have actually no idea what situation it handles. >> Comments? > > This looks reasonable. The test you mention is to make sire that at any > time the cursor is in front of an inset. At the beginning, the selection > probably starts on some text, so if it better to jump to the next inset. Ok, I added some comment to the routines. > The usual way to test for insets in the code is to compare the lyxCode() > value, rather than a layout name string. At least the compiler will check > that you are testing against a value that makes sense. Yes, I realized that after sending the patch. Improved version attached, will commit unless some objections are raised. Pavel diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc index 3e490927be..9acf334562 100644 --- a/lib/ui/stdcontext.inc +++ b/lib/ui/stdcontext.inc @@ -358,6 +358,7 @@ Menuset Item "Apply Last Text Style|A" "textstyle-apply" Submenu "Text Style|x" "edit_textstyles" Item "Paragraph Settings...|P" "layout-paragraph" + OptItem "Unify Graphics Groups|U" "graphics-unify" LanguageSelector Separator Item "Fullscreen Mode" "ui-toggle fullscreen" diff --git a/src/BufferView.cpp b/src/BufferView.cpp index b2e3186b17..ad8ed46e58 100644 --- a/src/BufferView.cpp +++ b/src/BufferView.cpp @@ -1151,6 +1151,10 @@ bool BufferView::getStatus(FuncRequest const & cmd, FuncStatus & flag) flag.setEnabled(true); break; + case LFUN_GRAPHICS_UNIFY: + flag.setEnabled(cur.selection()); + break; + case LFUN_WORD_FINDADV: { FindAndReplaceOptions opt; istringstream iss(to_utf8(cmd.argument())); @@ -1697,6 +1701,47 @@ void BufferView::dispatch(FuncRequest const & cmd, DispatchResult & dr) break; } + case LFUN_GRAPHICS_UNIFY: { + + cur.recordUndoFullBuffer(); + + DocIterator from, to; + from = cur.selectionBegin(); + to = cur.selectionEnd(); + + string newId = cmd.getArg(0); + bool fetchId=newId.empty(); //if we wait for groupId from first graphics inset + + InsetGraphicsParams grp_par; + InsetGraphics::string2params(graphics::getGroupParams(buffer_, newId), buffer_, grp_par); + + if (!from.nextInset()) //move to closest inset + from.forwardInset(); + + while (!from.empty() && from < to) { + Inset * inset = from.nextInset(); + if (!inset) + break; + if (inset->lyxCode() == GRAPHICS_CODE) { + InsetGraphics * ig = inset->asInsetGraphics(); + if (!ig) + break; + InsetGraphicsParams inspar = ig->getParams(); + if (fetchId) { + grp_par = inspar; + fetchId = false; + + } else { + grp_par.filename = inspar.filename; + ig->setParams(grp_par); + } + } + from.forwardInset(); + } + dr.screenUpdate(Update::Force); //needed if triggered from context menu + break; + } + case LFUN_STATISTICS: { DocIterator from, to; if (cur.selection()) { diff --git a/src/FuncCode.h b/src/FuncCode.h index 4a5983147d..cce61f0df5 100644 --- a/src/FuncCode.h +++ b/src/FuncCode.h @@ -476,7 +476,8 @@ enum FuncCode LFUN_DEVEL_MODE_TOGGLE, // lasgouttes 20170723 //370 LFUN_EXPORT_CANCEL, // rgh, 20171227 - LFUN_BUFFER_ANONYMIZE, // sanda, 20180201 + LFUN_BUFFER_ANONYMIZE, // sanda, 20180201 + LFUN_GRAPHICS_UNIFY,// sanda, 20180207 LFUN_LASTACTION // end of the table }; diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp index 193c822cd2..a4bc7d1fad 100644 --- a/src/LyXAction.cpp +++ b/src/LyXAction.cpp @@ -3555,6 +3555,17 @@ void LyXAction::init() */ { LFUN_SET_GRAPHICS_GROUP, "set-graphics-group", Noop, Edit }, +/*! + * \var lyx::FuncCode lyx::LFUN_GRAPHICS_UNIFY + * \li Action: Set the same group for all graphics insets in the marked block. + * \li Syntax: graphics-unify
[patch] Chapter top spacing - regression
Hi, I already wrote about this some time ago, switching to 2.3 made going through the documents with chapters somewhat annoying on small screens because third of my monitor is taken by vertical space. Eg. after loading tutorial on my laptop I can't read even the first paragraph because of the empty space. This was not the case with 2.0 as you can see in attached screenshot (little blurry due to high compression). Left-most lyx 2.0, middle lyx 2.3, right lyx 2.3 with the attached patch. I look at git history and the change was not caused by the layout file, so my speculation is that some painting routines changed. Anyway I propose to change the layout file as it seems most straightfoward. Opinions? Pavel diff --git a/lib/layouts/stdsections.inc b/lib/layouts/stdsections.inc index c8c2ece..fbd16fa 100644 --- a/lib/layouts/stdsections.inc +++ b/lib/layouts/stdsections.inc @@ -56,7 +56,7 @@ Style Chapter NextNoIndent 1 ToggleIndent Never ParSkip 0.4 - TopSep4 + TopSep2 BottomSep 0.8 ParSep0.8 Align Block
Re: [Patch] Unify groups LFUN
Le 07/02/2018 à 20:12, Pavel Sanda a écrit : Something like what inset-forall does? The idea is to use an InsetIterator (just a DocIterator that does forwardInset() with operator++ and returns the inset with operator*. Then one has to check the inset code by hand (which is not nice IMO). But I need range from [cur.selectionBegin();cur.selectionEnd()] so neither of proposed ideas works in straightforward way. inset-forall should be improved to limit itself to current selection if needed. This is what I come up with, if (!from.nextInset()) line is taken from inset-forall but I have actually no idea what situation it handles. Comments? This looks reasonable. The test you mention is to make sire that at any time the cursor is in front of an inset. At the beginning, the selection probably starts on some text, so if it better to jump to the next inset. The usual way to test for insets in the code is to compare the lyxCode() value, rather than a layout name string. At least the compiler will check that you are testing against a value that makes sense. JMarc
[Patch] Unify groups LFUN (was: [LyX/master] Add missing break and polish formatting)
Jean-Marc Lasgouttes wrote: >>> Here is what I had in mind. Works quite well. >> Who would have guessed what the innocent commit of such esoteric lfun >> would trigger :) > > It is still small activity :) Does it work for you? Will try tomorrow. >> But since I caught your attention, would you mind writing down dociterator >> loop through all graphic insets, which are currently marked in the block? I >> need similar but more useful lfun in which all graphic insets get the same >> group ID (by eg the first one). I see hints in DocIterator.h, but the >> description of methods is not clear enough to just use it instead of >> studying the whole iterator class to be sure what I am doing... > > Something like what inset-forall does? > > The idea is to use an InsetIterator (just a DocIterator that does > forwardInset() with operator++ and returns the inset with operator*. Then one > has to check the inset code by hand (which is not nice IMO). But I need range from [cur.selectionBegin();cur.selectionEnd()] so neither of proposed ideas works in straightforward way. This is what I come up with, if (!from.nextInset()) line is taken from inset-forall but I have actually no idea what situation it handles. Comments? Pavel diff --git a/src/BufferView.cpp b/src/BufferView.cpp index b2e3186b17..110abadb3c 100644 --- a/src/BufferView.cpp +++ b/src/BufferView.cpp @@ -1151,6 +1151,10 @@ bool BufferView::getStatus(FuncRequest const & cmd, FuncStatus & flag) flag.setEnabled(true); break; + case LFUN_GRAPHICS_UNIFY: + flag.setEnabled(cur.selection()); + break; + case LFUN_WORD_FINDADV: { FindAndReplaceOptions opt; istringstream iss(to_utf8(cmd.argument())); @@ -1697,6 +1701,48 @@ void BufferView::dispatch(FuncRequest const & cmd, DispatchResult & dr) break; } + case LFUN_GRAPHICS_UNIFY: { + + cur.recordUndoFullBuffer(); + + DocIterator from, to; + from = cur.selectionBegin(); + to = cur.selectionEnd(); + + string newId = cmd.getArg(0); + bool fetchId=newId.empty(); //if we wait for groupId from first graphics inset + + string grp = graphics::getGroupParams(buffer_, newId); + InsetGraphicsParams grp_par; + InsetGraphics::string2params(grp, buffer_, grp_par); + + if (!from.nextInset()) //how this happens? + from.forwardInset(); + + while (!from.empty() && from < to) { + Inset * inset = from.nextInset(); + if (!inset) + break; + docstring insname = inset->layoutName(); + if (insname == "Graphics") { + InsetGraphics * ig = inset->asInsetGraphics(); + if (!ig) + break; + InsetGraphicsParams inspar = ig->getParams(); + if (fetchId) { + grp_par = inspar; + fetchId = false; + + } else { + grp_par.filename = inspar.filename; + ig->setParams(grp_par); + } + } + from.forwardInset(); + } + break; + } + case LFUN_STATISTICS: { DocIterator from, to; if (cur.selection()) { diff --git a/src/FuncCode.h b/src/FuncCode.h index 4a5983147d..cce61f0df5 100644 --- a/src/FuncCode.h +++ b/src/FuncCode.h @@ -476,7 +476,8 @@ enum FuncCode LFUN_DEVEL_MODE_TOGGLE, // lasgouttes 20170723 //370 LFUN_EXPORT_CANCEL, // rgh, 20171227 - LFUN_BUFFER_ANONYMIZE, // sanda, 20180201 + LFUN_BUFFER_ANONYMIZE, // sanda, 20180201 + LFUN_GRAPHICS_UNIFY,// sanda, 20180207 LFUN_LASTACTION // end of the table }; diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp index 193c822cd2..a4bc7d1fad 100644 --- a/src/LyXAction.cpp +++ b/src/LyXAction.cpp @@ -3555,6 +3555,17 @@ void LyXAction::init() */ { LFUN_SET_GRAPHICS_GROUP, "set-graphics-group", Noop, Edit }, +/*! + * \var lyx::FuncCode lyx::LFUN_GRAPHICS_UNIFY + * \li Action: Set the same group for all graphics insets in the marked block. + * \li Syntax: graphics-unify [] + * \li Params: : Id for an existing group. In case the Id is an empty string, +the group Id from the first graphics inset will be used. + *
Re: Extending layouts
On 24.01.2018 21:22, Richard Heck wrote: On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote: Now that I think about it, the advantage of using a special syntax is that there is not need to specify the file name, which makes the code safer. Idead of syntax: Input Input * InputParent I had a similar thought: something like class inheritance. The last of these looks best to me. And seems to get the job done I need at the moment. So, I'd be happy is something like this existed. Daniel
Re: [LyX/master] Add missing break and polish formatting.
Le 07/02/2018 à 16:44, Pavel Sanda a écrit : Jean-Marc Lasgouttes wrote: It is :) Given that one needs this lfun twice per year, I don't think that's a big deal... Pavel Here is what I had in mind. Works quite well. Who would have guessed what the innocent commit of such esoteric lfun would trigger :) It is still small activity :) Does it work for you? But since I caught your attention, would you mind writing down dociterator loop through all graphic insets, which are currently marked in the block? I need similar but more useful lfun in which all graphic insets get the same group ID (by eg the first one). I see hints in DocIterator.h, but the description of methods is not clear enough to just use it instead of studying the whole iterator class to be sure what I am doing... Something like what inset-forall does? The idea is to use an InsetIterator (just a DocIterator that does forwardInset() with operator++ and returns the inset with operator*. Then one has to check the inset code by hand (which is not nice IMO). The situation would be better if we could declare lyxCode() as "static virtual" for for some reason C++ does not allow that. The we would be able to compare inset.lyxCode() to InsetGraphics::lyxCode(). It might be though that the correct answer here is to use rtti (dynamic_cast). JMarc
Re: [LyX/master] Add missing break and polish formatting.
Jean-Marc Lasgouttes wrote: >> It is :) >> Given that one needs this lfun twice per year, I don't think that's a big >> deal... >> Pavel > > Here is what I had in mind. Works quite well. Who would have guessed what the innocent commit of such esoteric lfun would trigger :) But since I caught your attention, would you mind writing down dociterator loop through all graphic insets, which are currently marked in the block? I need similar but more useful lfun in which all graphic insets get the same group ID (by eg the first one). I see hints in DocIterator.h, but the description of methods is not clear enough to just use it instead of studying the whole iterator class to be sure what I am doing... Pavel
Re: [LyX/master] Add missing break and polish formatting.
Le 07/02/2018 à 11:29, Pavel Sanda a écrit : Jean-Marc Lasgouttes wrote: Am I right that this does 40+ full-document search and replace? Performance on LyX User Guide is terrible, but seeing the document change by letter groups is quite amusing. Then LyX needs 2.4G of memory due to undo and performance of undo is abysmal. It is :) Given that one needs this lfun twice per year, I don't think that's a big deal... Pavel Here is what I had in mind. Works quite well. JMarc From 8879bd98ab5ffa5736c6aee3467fbcde75c20810 Mon Sep 17 00:00:00 2001 From: Jean-Marc LasgouttesDate: Wed, 7 Feb 2018 15:35:46 +0100 Subject: [PATCH] Implement buffer-anonymize more efficiently The work is done now in Paragraph::anonymize(). Move the handling of the lfun to Buffer class. --- src/Buffer.cpp | 18 ++ src/BufferView.cpp | 10 -- src/Paragraph.cpp | 9 + src/Paragraph.h| 4 4 files changed, 27 insertions(+), 14 deletions(-) diff --git a/src/Buffer.cpp b/src/Buffer.cpp index ff85f22..11093a5 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -2573,15 +2573,16 @@ bool Buffer::getStatus(FuncRequest const & cmd, FuncStatus & flag) flag.setOnOff(params().output_changes); break; - case LFUN_BUFFER_TOGGLE_COMPRESSION: { + case LFUN_BUFFER_TOGGLE_COMPRESSION: flag.setOnOff(params().compressed); break; - } - case LFUN_BUFFER_TOGGLE_OUTPUT_SYNC: { + case LFUN_BUFFER_TOGGLE_OUTPUT_SYNC: flag.setOnOff(params().output_sync); break; - } + + case LFUN_BUFFER_ANONYMIZE: + break; default: return false; @@ -2857,6 +2858,15 @@ void Buffer::dispatch(FuncRequest const & func, DispatchResult & dr) params().output_sync = !params().output_sync; break; + case LFUN_BUFFER_ANONYMIZE: { + undo().recordUndoFullBuffer(CursorData()); + CursorData cur(doc_iterator_begin(this)); + for ( ; cur ; cur.forwardPar()) + cur.paragraph().anonymize(); + dr.forceBufferUpdate(); + break; + } + default: dispatched = false; break; diff --git a/src/BufferView.cpp b/src/BufferView.cpp index b2e3186..7659f03 100644 --- a/src/BufferView.cpp +++ b/src/BufferView.cpp @@ -1134,7 +1134,6 @@ bool BufferView::getStatus(FuncRequest const & cmd, FuncStatus & flag) case LFUN_WORD_FIND_FORWARD: case LFUN_WORD_FIND_BACKWARD: case LFUN_WORD_REPLACE: - case LFUN_BUFFER_ANONYMIZE: case LFUN_MARK_OFF: case LFUN_MARK_ON: case LFUN_MARK_TOGGLE: @@ -1618,15 +1617,6 @@ void BufferView::dispatch(FuncRequest const & cmd, DispatchResult & dr) break; } - case LFUN_BUFFER_ANONYMIZE: { - for (char c = '0'; c <= 'Z'; c++) { - odocstringstream ss; - ss << "a\n" << c << "\n0 0 1 1 0"; - lyx::dispatch(FuncRequest(LFUN_WORD_REPLACE, ss.str())); - } - break; - } - case LFUN_WORD_FINDADV: { FindAndReplaceOptions opt; istringstream iss(to_utf8(cmd.argument())); diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp index 4ee612b..bc7bbee 100644 --- a/src/Paragraph.cpp +++ b/src/Paragraph.cpp @@ -4148,6 +4148,15 @@ SpellChecker::Result Paragraph::spellCheck(pos_type & from, pos_type & to, } +void Paragraph::anonymize() +{ + // This is a very crude anonymization for now + for (char_type & c : d->text_) + if (isLetterChar(c) || isNumber(c)) + c = 'a'; +} + + void Paragraph::Private::markMisspelledWords( pos_type const & first, pos_type const & last, SpellChecker::Result result, diff --git a/src/Paragraph.h b/src/Paragraph.h index 790c3f2..84fcf75 100644 --- a/src/Paragraph.h +++ b/src/Paragraph.h @@ -505,6 +505,10 @@ public: /// presently used only in the XHTML output routines. std::string magicLabel() const; + /// anonymizes the paragraph contents (but not the paragraphs + /// contained inside it. Does not handle undo. + void anonymize(); + private: /// Expand the counters for the labelstring of \c layout docstring expandParagraphLabel(Layout const &, BufferParams const &, -- 2.7.4
Re: integral upper limit adjacent to integral sign
On Wed, Feb 07, 2018 at 12:06:13PM +0100, Jean-Marc Lasgouttes wrote: > Le 07/02/2018 à 11:56, Enrico Forestieri a écrit : > > On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote: > > > On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote: > > > > > > > Enrico, for reference this is the commit where we use > > > > QFontMetrics::width in some cases instead of the QTextLayout thing. > > > > > > > > I tried to revert it and did not see much difference. > > > > > > I tried a vanilla "git revert" on master and there was a conflict so I > > > did not look further. If you have a patch that reverts it, I could test > > > that. > > > > Please, try the attached. > > > > Enrico, is it a matter of taking into account the left/right bearing for > math symbols? Because this is the difference between naturalWidth and > horizontalAdvance AFAICS. And this is what I did not try when doing a revert > "by hand" (see attachment) that did not show any change. Most probably. Then, I don't know why it is different between Qt4 and Qt5. -- Enrico
LyX 2.2.3 problem: There is no (U+200C) in font TeXGyreCursor
To see the problem, set the typewriter font to "Tex Gyre Cursor". Check "Use non-TeX fonts (via XeTeX/LuaTeX)" Now, write something like "cat >> myfile.txt" (for a linux tutorial) Set the text style to "code", or customize it to "typewriter", or use the paragraph style "LyX Code". Any way of invoking typewriter, will, upon PDF export, yield a variant of: Missing character: There is no <200c> in font TeX Gyre Cursor/OT:script=latn;languag In some cases, the 200c is invisible (it is a unicode zero-width non-joiner - so it will not render any symbol) and that makes the error message hard to read. Also, there should be no such error message because I did not enter any zero-width non-joiner. Is this some attempt at preventing ">>" from turning into a guillemet (»)? Tex Gyre Termes (improved clone of Times Roman) seems to have the same problem. Set this as the main font, and type >> in plain text and it breaks. It seems to me that something is broken with "Use non-TeX fonts"? Or is the TeX Gyre font collection considered broken? My obvious workaround is to insert a ligature break, but that does not remove all the error messages. Inserting an empty vertical phantom works - but it is a kludge. It'd be so much nicer if typing >> would just work. Helge Hafting
Re: integral upper limit adjacent to integral sign
Le 07/02/2018 à 11:56, Enrico Forestieri a écrit : On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote: On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote: Enrico, for reference this is the commit where we use QFontMetrics::width in some cases instead of the QTextLayout thing. I tried to revert it and did not see much difference. I tried a vanilla "git revert" on master and there was a conflict so I did not look further. If you have a patch that reverts it, I could test that. Please, try the attached. Enrico, is it a matter of taking into account the left/right bearing for math symbols? Because this is the difference between naturalWidth and horizontalAdvance AFAICS. And this is what I did not try when doing a revert "by hand" (see attachment) that did not show any change. JMarc diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp index b9eab85..24fa294 100644 --- a/src/frontends/qt4/GuiFontMetrics.cpp +++ b/src/frontends/qt4/GuiFontMetrics.cpp @@ -187,13 +187,13 @@ int GuiFontMetrics::width(docstring const & s) const * safety measure, always use QMetrics::width with our math fonts. */ int w = 0; - if (s.length() == 1 -#if QT_VERSION >= 0x040800 - || font_.styleName() == "LyX" -#endif - ) - w = metrics_.width(toqstr(s)); - else { +// if (s.length() == 1 +// #if QT_VERSION >= 0x040800 +// || font_.styleName() == "LyX" +// #endif +// ) +// w = metrics_.width(toqstr(s)); +// else { QTextLayout tl; tl.setText(toqstr(s)); tl.setFont(font_); @@ -201,7 +201,7 @@ int GuiFontMetrics::width(docstring const & s) const QTextLine line = tl.createLine(); tl.endLayout(); w = iround(line.horizontalAdvance()); - } +// } strwidth_cache_.insert(s, w, s.size() * sizeof(char_type)); return w; }
Re: integral upper limit adjacent to integral sign
On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote: > On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote: > > > Enrico, for reference this is the commit where we use > > QFontMetrics::width in some cases instead of the QTextLayout thing. > > > > I tried to revert it and did not see much difference. > > I tried a vanilla "git revert" on master and there was a conflict so I > did not look further. If you have a patch that reverts it, I could test > that. Please, try the attached. -- Enrico diff --git a/lib/symbols b/lib/symbols index 31ba7f0eb1..82a6d132d5 100644 --- a/lib/symbols +++ b/lib/symbols @@ -314,7 +314,7 @@ spadesuit cmsy127 170 mathord lyxnot cmsy 54 47 mathrel / hiddensymbol iffont cmsy # kerning is slightly imperfect so that one can see when \not is selected -\def\not{\lyxnot} +\def\not{\lyxnot\mathrel{\kern-11mu}} else \def\not{\kern4mu\lyxnot\kern-19mu} endif @@ -991,11 +991,11 @@ bignplus stmry 112 0 mathop x stmaryrd # caution: named hugenpl \def\varcopyright{\mathord{c\kern-11mu\varbigcirc}} stmaryrd # kerning is slightly imperfect so that one sees when \[Aa]rrownot is selected -\def\arrownot{\lyxarrownot} stmaryrd -\def\Arrownot{\lyxArrownot\mathrel{\kern0.5mu}} stmaryrd +\def\arrownot{\lyxarrownot\mathrel{\kern-11mu}} stmaryrd +\def\Arrownot{\lyxArrownot\mathrel{\kern-10.5mu}} stmaryrd \def\longarrownot{\mathrel{\kern5.5mu}\arrownot\mathrel{\kern-5.5mu}} stmaryrd \def\Longarrownot{\mathrel{\kern5.5mu}\Arrownot\mathrel{\kern-5.5mu}} stmaryrd -\def\Mapsto{\Mapstochar\mathrel\Rightarrow} mathrel stmaryrd +\def\Mapsto{\Mapstochar\mathrel{\kern-2mu}\Rightarrow} mathrel stmaryrd \def\mapsfrom{\leftarrow\kern-9mu\mapsfromchar} mathrel stmaryrd \def\Mapsfrom{\Leftarrow\kern-9mu\Mapsfromchar} mathrel stmaryrd \def\Longmapsto{\Mapstochar\Longrightarrow} mathrel stmaryrd @@ -1174,7 +1174,7 @@ iffont cmsy \def\Longleftarrow{\Leftarrow\joinrel\Relbar} mathrel \def\implies{\Longrightarrow} mathrel amsmath \def\impliedby{\Longleftarrow} mathrel amsmath -\def\mapsto{\mapstochar\rightarrow} mathrel +\def\mapsto{\mapstochar\mathrel{\kern-2mu}\rightarrow} mathrel \def\longmapsto{\mapstochar\joinrel\relbar\joinrel\rightarrow} mathrel \def\models{\mathrel{\vert}\joinrel\Relbar} mathrel else diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp index b9eab8531f..43eb4f20e7 100644 --- a/src/frontends/qt4/GuiFontMetrics.cpp +++ b/src/frontends/qt4/GuiFontMetrics.cpp @@ -180,28 +180,16 @@ int GuiFontMetrics::width(docstring const & s) const PROFILE_THIS_BLOCK(width); if (strwidth_cache_.contains(s)) return strwidth_cache_[s]; + // For some reason QMetrics::width returns a wrong value with Qt5 + // int w = metrics_.width(toqstr(s)); PROFILE_CACHE_MISS(width); - /* For some reason QMetrics::width returns a wrong value with Qt5 -* with some arabic text. OTOH, QTextLayout is broken for single -* characters with null width (like \not in mathed). Also, as a -* safety measure, always use QMetrics::width with our math fonts. - */ - int w = 0; - if (s.length() == 1 -#if QT_VERSION >= 0x040800 - || font_.styleName() == "LyX" -#endif - ) - w = metrics_.width(toqstr(s)); - else { - QTextLayout tl; - tl.setText(toqstr(s)); - tl.setFont(font_); - tl.beginLayout(); - QTextLine line = tl.createLine(); - tl.endLayout(); - w = iround(line.horizontalAdvance()); - } + QTextLayout tl; + tl.setText(toqstr(s)); + tl.setFont(font_); + tl.beginLayout(); + QTextLine line = tl.createLine(); + tl.endLayout(); + int w = int(line.naturalTextWidth()); strwidth_cache_.insert(s, w, s.size() * sizeof(char_type)); return w; }
Re: [LyX/master] Add missing break and polish formatting.
Jean-Marc Lasgouttes wrote: > Am I right that this does 40+ full-document search and replace? Performance > on LyX User Guide is terrible, but seeing the document change by letter > groups is quite amusing. Then LyX needs 2.4G of memory due to undo and > performance of undo is abysmal. It is :) Given that one needs this lfun twice per year, I don't think that's a big deal... Pavel