Re: Document output format PDF(LuaTeX) .. instant preview of math
On Sat, Nov 05, 2016 at 11:40:51AM +0100, Kornel Benko wrote: > Try to open attached document. > Wait a moment until the preview is done. > The formula takes too much space. I thought someone had responded to this but I can't find it. We should make a bug report so we don't forget. Scott signature.asc Description: PGP signature
Re: problems with quotes
Dear Jean-Marc, On 2016-12-08, Jean-Marc Lasgouttes wrote: > Le 08/12/2016 à 00:09, Guenter Milde a écrit : >> * consistency: currently, if a user sees a guillemot « on screen, it can be >> a literal character or a Quote inset and the LaTeX export can be >> "«" or "\guillemotleft" (depending on the "inputencoding") >> "<<" (for Quote inset, even if « is supported by the encoding) > This code is old and shall be audited. But this has nothing to do with > keeping or not a quote inset. Yes and no: * Consistency in the LaTeX output can be achieved also when keeping the Quote inset. * Other inconsistencies remain or must be overcome with additional complexity in the LyX code, e.g. Edit>Find finds the literal character but not the Quote inset OTOH, the current functionality (except for not using literal characters in the LaTeX output) can be achieved with literal Unicode characters: * The "smart" part of the quote-insert function and the \quotes_language setting control insertion, not export. Once inserted, a Quote insert is as immutable as a literal character. -> changing the appearance of Quote insets document-wide is harder than changing literal quote characters as the regular find/replace does not work. Replacing the Quote inset would simplify the LyX code without loss of existing features. Keeping the Quote inset would allow to add feature requests: * "dynamic" Quotes where the appearance is determinded by the \quotes_language setting at export time. * "configurable" Quotes (with context-menu to modify settings) Günter
Re: LyX 2.2 slowness
In case it might help, this seems a recurrent stack trace during the slowness writev,??,??,xcb_writev,_XSend,XRenderAddGlyphs,QFontEngineX11FT::uploadGlyphToServer(QFontEngineFT::QGlyphSet*,, QFontEngineFT::loadGlyph(QFontEngineFT::QGlyphSet*,,QFontEngineFT::recalcAdvances(QGlyphLayout*,,??,??,??,??, QTextEngine::shapeTextWithHarfbuzz(int),QTextEngine::shapeText(int),QTextEngine::shape(int) likely with this sequel [1], so the innermost LyX code seems: lyx::frontend::GuiFontMetrics::breakAt,lyx::Row::Element::breakAt, lyx::Row::shortenIfNeeded,lyx::TextMetrics::breakRow,lyx::TextMetrics::redoParagraph, Now, I'm just moving the cursor and sometimes selecting with Shift down, so do we actually need to redoParagraph() ? Thanks, T. [1] writev,??,??,xcb_writev,_XSend,XRenderAddGlyphs,QFontEngineX11FT::uploadGlyphToServer(QFontEngineFT::QGlyphSet*,, QFontEngineFT::loadGlyph(QFontEngineFT::QGlyphSet*,,QFontEngineFT::recalcAdvances(QGlyphLayout*,,??,??,??,??, QTextEngine::shapeTextWithHarfbuzz(int),QTextEngine::shapeText(int),QTextEngine::shape(int), QTextLine::layout_helper(int),lyx::frontend::GuiFontMetrics::breakAt,lyx::Row::Element::breakAt, lyx::Row::shortenIfNeeded,lyx::TextMetrics::breakRow,lyx::TextMetrics::redoParagraph, lyx::BufferView::updateMetrics,lyx::BufferView::processUpdateFlags,lyx::BufferView::mouseEventDispatch, lyx::frontend::GuiWorkArea::Private::dispatch,lyx::frontend::GuiWorkArea::mousePressEvent,QWidget::event(QEvent*), QFrame::event(QEvent*),QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*,, QApplicationPrivate::notify_helper(QObject*,,QApplication::notify(QObject*,,lyx::frontend::GuiApplication::notify, QCoreApplication::notifyInternal(QObject*,,QApplicationPrivate::sendMouseEvent(QWidget*,,??, QApplication::x11ProcessEvent(_XEvent*),??,g_main_context_dispatch,??,g_main_context_iteration, QEventDispatcherGlib::processEvents(QFlags),??, QEventLoop::processEvents(QFlags), QEventLoop::exec(QFlags),QCoreApplication::exec(), lyx::frontend::GuiApplication::exec,lyx::LyX::exec,main On 08/12/2016 12:36, Tommaso Cucinotta wrote: On 08/12/2016 11:09, Tommaso Cucinotta wrote: I'm now trying oprofile/operf, just to compare output. that's quite similar CPU_CLK_UNHALT...| samples| %| -- 1873080 100.000 lyx CPU_CLK_UNHALT...| samples| %| -- 1636151 87.3508 libfreetype.so.6.12.3 70092 3.7421 libQtGui.so.4.8.7 64930 3.4665 libc-2.24.so 52064 2.7796 libQtCore.so.4.8.7 27387 1.4621 kallsyms 7808 0.4169 libXrender.so.1.3.0 4479 0.2391 libX11.so.6.3.0 4366 0.2331 libstdc++.so.6.0.22 2532 0.1352 ld-2.24.so 1226 0.0655 lyx 866 0.0462 libxcb.so.1.1.0 651 0.0348 libpthread-2.24.so 275 0.0147 libglib-2.0.so.0.5000.0 40 0.0021 libqgif.so 30 0.0016 libdbus-1.so.3.14.7 29 0.0015 libgdk-x11-2.0.so.0.2400.30 T.
Re: problems with quotes
Dear Jürgen,
On 2016-12-08, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 07.12.2016, 23:09 + schrieb Guenter Milde:
>> However, given that other non-ASCII characters are exported as-is, too
>> using literal characters for typographical quotes makes the generated
>> document's source more consistent and easier to read.
>> Also:
>> +1 get rid of the dependance on "TeX ligatures" with non-TeX fonts
> I am not sure we do not need these ligatures in other cases.
Nor am I, but it would be a step in the right direction in any case.
IMO, LyX should not actively use these "archaic" conventions intended
for easier input with an american keyboard.
>> > Querying fontenc is not really something problematic.
>> However, if we can do without, the code becomes simpler and less
>> error-prone.
My remark was about LyX code
> Not in all cases. My documents, for instance, will break, since I have
> activated » and « for the use with csquotes, as many csquotes users do:
> \MakeAutoQuote{»}{«}
> So literal guillemot glyphs change in output depending on the context.
> In parallel, I am using the LyX quotes for static quotes, and if I
> enter a guillemot there, I expect it to come out as a guillemet in any
> case, thus it needs to be output as a macro or ligature.
OK. I understand the question about "active chars" now.
You set the "\quotes_language" to french or danish and press " for a
guillemet in the output and » or « for a "csquotes auto quote".
In LyX, you cannot distinguish one from the other unless you open the
"source pane". For the average user, different behaviour in the output
will be a bad surprise!
>> > I really do not see what we will gain here.
>> * consistency: currently, if a user sees a guillemot « on screen, it
>> can be
>> a literal character or a Quote inset and the LaTeX export can be
>>
>> "«" or "\guillemotleft" (depending on the "inputencoding")
>> "<<" (for Quote inset, even if « is supported by the encoding)
> What is crucial for most LyX users is the output, not the intermediate
> LaTeX source.
... unless
* the differences lead to hard to detect errors in the output like
csquotes ignoring a quote that looks like the one set in
\MakeAutoQuote{»}{«}
* users share documents with co-authors working with LaTeX
* users try to find the string "hallo «Welt»" somewhere in the document.
Günter
Re: #10481: Hardening LyX against potential misuse
Le 05/12/2016 à 08:53, Tommaso Cucinotta a écrit : On 04/12/2016 18:51, Guillaume Munch wrote: Le 04/12/2016 à 18:06, Tommaso Cucinotta a écrit : On 28/11/2016 00:42, Tommaso Cucinotta wrote: On 27/11/2016 13:52, Guillaume Munch wrote: * Converters>Security is located below the converter configuration, which leads to think that they are converter properties instead of global settings. What about placing it above the converter list? Same problem with the Converter Cache option already, isn't it? Let me propose the attached fix for both at once. just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm it shows up as intended ... How is it supposed to show up? Can you send a screenshot? Here only the font of "Converters Definition" changed, and I still find it unclear. Here you go: screenshots before and after the patch attached. With the "Converter Definitions" label now at the same highlight/logical level as "Converter File Cache" and "Security" ones, I think there is no more the confusionabout which options in the dialog are specific to a single converter. Thanks. I see the same. I agree that it is already better.
Re: #10481: Hardening LyX against potential misuse
Le 05/12/2016 à 08:36, Tommaso Cucinotta a écrit : On 04/12/2016 18:37, Guillaume Munch wrote: If there are n graphics, then are there n dialogs when opening the file for the first time? it asks as many times as there are (uncached) graphics needing 'needauth' converters,unless you hit the "Run, and don't ask again for the same doc" button. I guess this is better than nothing. Is this why you wanted the "don't warn again" checkbox on the other dialog?
Re: compilation error with current master
Le 07/12/2016 à 13:57, Jan Niklas Hasse a écrit : Hi, try adding #include to Encoding.cpp. Yes On Wed, 7 Dec 2016, at 00:36, Uwe Stöhr wrote: With today's master I get this compilation error: Encoding.cpp D:\LyXGit\Master\src\Encoding.cpp(267): error C3861: 'back_inserter': identifier not found [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj] Thanks for the report.
Re: LyX 2.2 slowness
Le 08/12/2016 à 16:07, Jean-Marc Lasgouttes a écrit : Also, it would be nice to know what are the callers of freettype that consume the most time. As a reminder here is where I got last time with kcachegrind: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg194401.html The caching in Qt5 seems much lower-level than what you have access to, so it is not impossible that you can no longer get good performance with Qt4. Let us hope that your patch works.
Re: [LyX/master] Cosmetic changes to the needauth dialogs
Le 04/12/2016 à 19:59, Enrico Forestieri a écrit :
On Sun, Dec 04, 2016 at 06:38:42PM +0100, Guillaume Munch wrote:
+// FIXME: This dialog has issues with line breaking and size, in particular
with
+// html. But it could easily be reimplemented as a QMessageBox using
+// QMessageBox::setCheckBox() available starting from Qt 5.2
class GuiToggleWarningDialog : public QDialog, public Ui::ToggleWarningUi
{
public:
If this is true, it would be better to actually reimplement it and
conditionally compile for Qt >= 5.2, otherwise this risks staying so
for ever (or almost so).
I agree.
Re: LyX and (ancient) Hebrew
Le 08/12/2016 à 16:21, mn a écrit : Try to select what comes after the first colon (to the left) up until the second colon in the second line. Or in other words: what is just between those two. The selection will jump to the beginning of the first line (far right). This was not intended. If I understand correctly, this is bug #10424, which will be fixed in 2.2.3. JMarc
Re: LyX and (ancient) Hebrew
Le 08/12/2016 à 16:20, mn a écrit : Yes. But this means I loose the ability to immediately see whether or not this part was correctly assigned to a given language. I think there might be a better solution than to disable _a_ marking completely. A grey bar in the background? You can freely change the color of this underline, which is ugly by default. JMarc
Re: LyX and (ancient) Hebrew
Le 08/12/2016 à 16:20, mn a écrit : Yes. But this means I loose the ability to immediately see whether or not this part was correctly assigned to a given language. I think there might be a better solution than to disable _a_ marking completely. A grey bar in the background? You can freely change the color of this underline, which is ugly by default. JMarc
Re: LyX and (ancient) Hebrew
On 08.12.16 15:45, Jean-Marc Lasgouttes wrote: > Le 08/12/2016 à 12:55, mn a écrit : >> Hm, I wonder if this is also effecting selecting rtl-text with the mouse. >> Right now it drives me crazy how it behaves once the text is marked as >> containig Hebrew and spans more than one row in the editor display. >> Cursor mode visual and logical seem to be in conflict here? > > Sorry, I am not sure what you mean. What is the observed behavior and > what is the desired one? > > Is this with logical or visual cursor movement? > > I have to say that we really lack a someone who cares about bidi text. I > rewrote large parts (because I had to) in 2.2, but there is still a lot > of weird code that nobody dares to even touch. See the attached file. Set your editor window size or zoom-level in such a way so that the first two big colon-like characters are on separate lines. (You may have to use something like Liberation as ScreenFont to recognize them) This is marked as Hebrew so it is rtl. Try to select what comes after the first colon (to the left) up until the second colon in the second line. Or in other words: what is just between those two. The selection will jump to the beginning of the first line (far right). This was not intended. Cursor movement was set to visual. Setting it to logical does not improve the situation. Mike Heb-select.lyx Description: application/lyx
Re: LyX and (ancient) Hebrew
On 08.12.16 15:41, Jean-Marc Lasgouttes wrote: > Le 08/12/2016 à 15:23, mn a écrit : >> That means: default document language is, say, English and then Hebrew >> is added in afterwards. >> Apart from the slight annoyance mentioned above it becomes very hard to >> actually type something with nikuds, since the >> "foreign-language-underline" (sorry, I do not know how it is called >> officially or in the sources) gets in the way. > > You cn disable this underline in preferences (look in Language Settings). > Yes. But this means I loose the ability to immediately see whether or not this part was correctly assigned to a given language. I think there might be a better solution than to disable _a_ marking completely. A grey bar in the background? >> On a side note: I would also appreciate something to quickly change the >> editor's zoom level. Is there a short-cut or can I define one? > > Ctrl+/Ctrl- or Ctrl with mouse wheel. > As I said: >> OS-wide display-zoom is soon too blurry to be practical. That would mean that Ctrl-Mousewheel behavior you mentioned, on Mac. But Cmd +/- in LyX is what I was looking for. Thx. Mike
Re: LyX 2.2 slowness
Le 08/12/2016 à 16:01, Tommaso Cucinotta a écrit : On 08/12/2016 14:39, Jean-Marc Lasgouttes wrote: On my ubuntu 12.40 station I get: Xft.dpi:96 Xft.antialias:1 Xft.hinting:1 Xft.hintstyle:hintslight Xft.rgba:none Xft.lcdfilter:none mine: Did you try the patch I posted, BTW? Also, it would be nice to know what are the callers of freettype that consume the most time. An option to see this is the new sysprof. I am still trying to make it work, though :) JMarc
Re: LyX 2.2 slowness
On 08/12/2016 14:39, Jean-Marc Lasgouttes wrote: On my ubuntu 12.40 station I get: Xft.dpi:96 Xft.antialias:1 Xft.hinting:1 Xft.hintstyle:hintslight Xft.rgba:none Xft.lcdfilter:none mine: tommaso@tommylap:~/lyx-trunk-ws/lyx$ xrdb -query |grep Xft Xft.antialias: 1 Xft.dpi:96 Xft.hinting:1 Xft.hintstyle: hintslight Xft.rgba: rgb T.
Re: LyX and (ancient) Hebrew
Le 08/12/2016 à 12:55, mn a écrit : Hm, I wonder if this is also effecting selecting rtl-text with the mouse. Right now it drives me crazy how it behaves once the text is marked as containig Hebrew and spans more than one row in the editor display. Cursor mode visual and logical seem to be in conflict here? Sorry, I am not sure what you mean. What is the observed behavior and what is the desired one? Is this with logical or visual cursor movement? I have to say that we really lack a someone who cares about bidi text. I rewrote large parts (because I had to) in 2.2, but there is still a lot of weird code that nobody dares to even touch. JMarc
Re: LyX and (ancient) Hebrew
Le 08/12/2016 à 15:41, Jean-Marc Lasgouttes a écrit : On a side note: I would also appreciate something to quickly change the editor's zoom level. Is there a short-cut or can I define one? Ctrl+/Ctrl- or Ctrl with mouse wheel. Sorry, you are a mac user. Use Command instead of Ctrl. JMarc
Re: LyX and (ancient) Hebrew
Le 08/12/2016 à 15:23, mn a écrit : That means: default document language is, say, English and then Hebrew is added in afterwards. Apart from the slight annoyance mentioned above it becomes very hard to actually type something with nikuds, since the "foreign-language-underline" (sorry, I do not know how it is called officially or in the sources) gets in the way. You cn disable this underline in preferences (look in Language Settings). On a side note: I would also appreciate something to quickly change the editor's zoom level. Is there a short-cut or can I define one? Ctrl+/Ctrl- or Ctrl with mouse wheel. JMarc
Re: LyX 2.2 slowness
Le 08/12/2016 à 14:29, Jean-Marc Lasgouttes a écrit : Le 08/12/2016 à 12:36, Tommaso Cucinotta a écrit : On 08/12/2016 11:09, Tommaso Cucinotta wrote: I'm now trying oprofile/operf, just to compare output. that's quite similar How do we know what are the freetype settings in effect (anitalisaing, hinting, ...)? OK, it is xrdb -query |grep Xft On my ubuntu 12.40 station I get: Xft.dpi:96 Xft.antialias: 1 Xft.hinting:1 Xft.hintstyle: hintslight Xft.rgba: none Xft.lcdfilter: none This means that I have slgight grayscale antialiasing. Note that AFAIK, subpixel aliasing does not work with LyX, since we paint on an intermediate Pixmap and not directly on screen. JMarc
Re: LyX 2.2 slowness
Le 08/12/2016 à 12:36, Tommaso Cucinotta a écrit : On 08/12/2016 11:09, Tommaso Cucinotta wrote: I'm now trying oprofile/operf, just to compare output. that's quite similar How do we know what are the freetype settings in effect (anitalisaing, hinting, ...)? JMarc
Re: LyX and (ancient) Hebrew
On 07.12.16 23:53, Scott Kostyshak wrote: > On Wed, Dec 07, 2016 at 10:35:06PM +0100, Cor Blom wrote: >> Op 03-12-16 om 22:51 schreef Scott Kostyshak: The other thing is that on screen, when I type a rtl text in a ltr documents, I have to mark that word as e.g. Hebrew before the sequence is right. I would be nice to have that done automatically. Xetex does it right, even if it is not marked as rtl. What would be great is an option to set not only a default rtl font, but also a default rtl language, that is set automatically by lyx in the document when rtl text is entered (and in Hebrew Lyx of course vice versa). >> >>> I don't understand, but that's probably because I know nothing about >>> RTL or fonts. You might want to make a trac ticket for this and describe >>> the feature in more detail. I'm guessing setting the component of the >>> ticket to "bidi" is best. >> >> Ticket #10514 > > Thanks for remembering to do this, even though you've been busy! I read > the ticket and I now understand (reading your original description I > realize it was clear now, I'm just a little slow sometimes...). Hm, I wonder if this is also effecting selecting rtl-text with the mouse. Right now it drives me crazy how it behaves once the text is marked as containig Hebrew and spans more than one row in the editor display. Cursor mode visual and logical seem to be in conflict here? Mike
Re: LyX 2.2 slowness
On 08/12/2016 11:09, Tommaso Cucinotta wrote: I'm now trying oprofile/operf, just to compare output. that's quite similar CPU_CLK_UNHALT...| samples| %| -- 1873080 100.000 lyx CPU_CLK_UNHALT...| samples| %| -- 1636151 87.3508 libfreetype.so.6.12.3 70092 3.7421 libQtGui.so.4.8.7 64930 3.4665 libc-2.24.so 52064 2.7796 libQtCore.so.4.8.7 27387 1.4621 kallsyms 7808 0.4169 libXrender.so.1.3.0 4479 0.2391 libX11.so.6.3.0 4366 0.2331 libstdc++.so.6.0.22 2532 0.1352 ld-2.24.so 1226 0.0655 lyx 866 0.0462 libxcb.so.1.1.0 651 0.0348 libpthread-2.24.so 275 0.0147 libglib-2.0.so.0.5000.0 40 0.0021 libqgif.so 30 0.0016 libdbus-1.so.3.14.7 29 0.0015 libgdk-x11-2.0.so.0.2400.30 T.
Re: LyX 2.2 slowness
On 08/12/2016 04:49, Richard Heck wrote:
I could do a valgrind thing of the same sort if you tell me what command
to run.
it's quite straightforward:
valgrind --tool=callgrind /usr/bin/lyx
# play with lyx, especially open a doc with a full page of text, move cursor
on it, select parts with shift+{r,l,u,d}, etc..., then quit
# you get a callgrind.out. file, open it with
kcachegrind ./callgrind.out.
I'm now trying oprofile/operf, just to compare output.
T.
Re: problems with quotes
Le 08/12/2016 à 00:09, Guenter Milde a écrit : * consistency: currently, if a user sees a guillemot « on screen, it can be a literal character or a Quote inset and the LaTeX export can be "«" or "\guillemotleft" (depending on the "inputencoding") "<<" (for Quote inset, even if « is supported by the encoding) This code is old and shall be audited. But this has nothing to do with keeping or not a quote inset. JMarc
