Re: \[ddd]dots in mathed
Scott Kostyshak wrote: > > > > You mean zoom-in changes the visual appearance for \dot in your > > > > environemnt? > > > > It does not change a single pixel here. Do you use linux? > > > > > > I have the same behavior as you, I think: \dot doesn't change at all > > > with zoom. \ddots does. > > > > After sitting on the code for a while I don't believe you :)) > > Perhaps I explained poorly. Here is a screencast for 2.3.x, showing \dot > and \\dots as I zoom: You explained properly, I did not read properly (\ddot != \ddots)... Pavel
Re: \[ddd]dots in mathed
On Fri, Mar 09, 2018 at 05:57:01PM +, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > > > > I've seen this in the past also, but only at high zoom levels. > > > > > > > > > > In other words, when you put \dot in mathed you see dot? > > > > > > > > For that one, I can indeed see that the dot is not a dot at low zoom > > > > levels as well. > > > > > > You mean zoom-in changes the visual appearance for \dot in your > > > environemnt? > > > It does not change a single pixel here. Do you use linux? > > > > I have the same behavior as you, I think: \dot doesn't change at all > > with zoom. \ddots does. > > After sitting on the code for a while I don't believe you :)) Perhaps I explained poorly. Here is a screencast for 2.3.x, showing \dot and \\dots as I zoom: https://www.dropbox.com/s/1x6uql5ugnoyvky/screencast-LQ-6142.ogv?dl=0 Scott signature.asc Description: PGP signature
Re: Update on 2.3.0 situation and Windows-specific issues
On 03/09/2018 09:16 AM, Uwe Stöhr wrote: > Am 09.03.2018 um 05:58 schrieb Uwe Stöhr: > >> Am 09.03.2018 um 05:34 schrieb Scott Kostyshak: >> >>> From what I understand, I think we still need to come to an >>> agreement on >>> whether to provide a dialog to the user asking if they would like to >>> either cancel the installation or proceed and have the installer update >>> MiKTeX. >> >> Please, I wrote now so many mails explaining the situation! I cannot >> do more. > > The feedback from user Elloh on the list encourages me to act. His > screwed MiKTeX was the result that the installer for LyX 2.2.3 cannot > update the system, even if you choose during the installation process > to do so. Therefore I fear that users installing LyX 2.2.3 will get > similar problems. > > Richard, can I release a new installer for LyX 2.2.3 or do you release > 2.2.4 within few days? We will be releasing 2.2.4 shortly. Richard
Re: [LyX/master] tex2lyx: chapterbib support
On 03/09/2018 07:32 AM, Jürgen Spitzmüller wrote: > Am Freitag, den 09.03.2018, 13:31 +0100 schrieb Juergen Spitzmueller: >> commit af6933c06f603beca3d8684f56217243cbff1f94 >> Author: Juergen Spitzmueller >> Date: Fri Mar 9 13:30:52 2018 +0100 >> >> tex2lyx: chapterbib support > Candidate for 2.3.2-staging. OK. rh
Re: \[ddd]dots in mathed
Scott Kostyshak wrote:
> > > > > I've seen this in the past also, but only at high zoom levels.
> > > >
> > > > In other words, when you put \dot in mathed you see dot?
> > >
> > > For that one, I can indeed see that the dot is not a dot at low zoom
> > > levels as well.
> >
> > You mean zoom-in changes the visual appearance for \dot in your environemnt?
> > It does not change a single pixel here. Do you use linux?
>
> I have the same behavior as you, I think: \dot doesn't change at all
> with zoom. \ddots does.
After sitting on the code for a while I don't believe you :))
\cdots might because it's a symbol...
The surprising fact is -- it's actually pretty hard to paint small rounded dot
without antialiasing and I spent two hours to try all kinds things from
like drawing circles to dotted lines etc.
Anyway below is the best patch I was able to produce and plan to commit.
Whether now, or after it's committed I would appreciate testing from someone
sitting on Win and Mac(?Retina) machine to check whether they see what I see
on linux for \dot and \ddot, i.e. the second attachment.
Pavel
diff --git a/src/mathed/MathSupport.cpp b/src/mathed/MathSupport.cpp
index 0e2dc81e7b..ea8309545f 100644
--- a/src/mathed/MathSupport.cpp
+++ b/src/mathed/MathSupport.cpp
@@ -82,6 +82,7 @@ namespace {
/*
* Internal struct of a drawing: code n x1 y1 ... xn yn, where code is:
* 0 = end, 1 = line, 2 = polyline, 3 = square line, 4 = square polyline
+ * 5 = rounded thick line (i.e. dot for short line)
*/
@@ -293,9 +294,18 @@ double const hline[] = {
};
+double const dot[] = {
+// 1, 0.5, 0.2, 0.5, 0.2,
+// 1, 0.4, 0.4, 0.6, 0.4,
+// 1, 0.5, 0.5, 0.5, 0.5,
+ 5, 0.4, 0.4, 0.6, 0.4,
+ 0
+};
+
+
double const ddot[] = {
- 1, 0.2, 0.5, 0.3, 0.5,
- 1, 0.7, 0.5, 0.8, 0.5,
+ 5, 0.0, 0.4, 0.3, 0.4,
+ 5, 0.6, 0.4, 1.0, 0.4,
0
};
@@ -333,12 +343,6 @@ double const dline3[] = {
};
-double const hlinesmall[] = {
- 1, 0.4, 0.5, 0.6, 0.5,
- 0
-};
-
-
double const ring[] = {
2, 5,
0.5, 0.8, 0.8, 0.5, 0.5, 0.2, 0.2, 0.5, 0.5, 0.8,
@@ -457,7 +461,7 @@ named_deco_struct deco_table[] = {
{"acute", slash, 0 },
{"tilde", tilde, 0 },
{"bar",hline, 0 },
- {"dot",hlinesmall, 0 },
+ {"dot",dot,0 },
{"check", angle, 1 },
{"breve", parenth,1 },
{"vec",arrow, 3 },
@@ -623,7 +627,7 @@ void mathed_draw_deco(PainterInfo & pi, int x, int y, int
w, int h,
for (int i = 0; d[i]; ) {
int code = int(d[i++]);
- if (code & 1) { // code == 1 || code == 3
+ if (code & 1) { // code == 1 || code == 3 || code == 5
double xx = d[i++];
double yy = d[i++];
double x2 = d[i++];
@@ -637,6 +641,16 @@ void mathed_draw_deco(PainterInfo & pi, int x, int y, int
w, int h,
int(x + xx + 0.5), int(y + yy + 0.5),
int(x + x2 + 0.5), int(y + y2 + 0.5),
pi.base.font.color());
+ if (code == 5) { // thicker, but rounded
+ pi.pain.line(
+ int(x + xx + 0.5+1), int(y + yy +
0.5-1),
+ int(x + x2 + 0.5-1), int(y + y2 +
0.5-1),
+ pi.base.font.color());
+ pi.pain.line(
+ int(x + xx + 0.5+1), int(y + yy +
0.5+1),
+ int(x + x2 + 0.5-1), int(y + y2 +
0.5+1),
+ pi.base.font.color());
+ }
} else {
int xp[32];
int yp[32];
Re: Update on 2.3.0 situation and Windows-specific issues
On Fri, Mar 09, 2018 at 04:58:07AM +, Uwe Stöhr wrote: > Am 09.03.2018 um 05:34 schrieb Scott Kostyshak: > > > From what I understand, I think we still need to come to an agreement on > > whether to provide a dialog to the user asking if they would like to > > either cancel the installation or proceed and have the installer update > > MiKTeX. > > Please, I wrote now so many mails explaining the situation! I cannot do > more. I agree that you cannot do more explaining. Thank you very much for your detailed explanations. What I ask is that you do more understanding. I have put a lot of effort into understanding your logic and your argument for why you think that silently updating MiKTeX is a reasonable thing to do. To me the logic and the end value of your argument is noble: If we do not update MiKTeX, the user will not have a workable LyX experience; therefore, we should update MiKTeX. That logic makes sense to me and is a valid argument. Do you understand the argument that I, Richard, Jean-Marc, and racoon have expressed (to those I cite, please correct me if I misrepresent your opinion)? Do you think it has a noble goal and a valid argument? If you do not understand our argument, then it is us that should do more explaining. If you have a specific question regarding the argument, please feel free to ask. Otherwise it is hard to know what specific part of the argument we should expand on. Only once both sides understand the argument of the other, without judgement, without comparing, just *understanding*, can we actually move to the next step of coming up with a solution. Thanks to everyone for their involvement in this discussion. It is not fun for anyone, and I know that everyone has the best experience of users as their goal. Scott signature.asc Description: PGP signature
Re: Update on 2.3.0 situation and Windows-specific issues
Am 09.03.2018 um 05:58 schrieb Uwe Stöhr: Am 09.03.2018 um 05:34 schrieb Scott Kostyshak: From what I understand, I think we still need to come to an agreement on whether to provide a dialog to the user asking if they would like to either cancel the installation or proceed and have the installer update MiKTeX. Please, I wrote now so many mails explaining the situation! I cannot do more. The feedback from user Elloh on the list encourages me to act. His screwed MiKTeX was the result that the installer for LyX 2.2.3 cannot update the system, even if you choose during the installation process to do so. Therefore I fear that users installing LyX 2.2.3 will get similar problems. Richard, can I release a new installer for LyX 2.2.3 or do you release 2.2.4 within few days? thanks and regards Uwe
Re: [LyX/master] tex2lyx: chapterbib support
Am Freitag, den 09.03.2018, 13:31 +0100 schrieb Juergen Spitzmueller: > commit af6933c06f603beca3d8684f56217243cbff1f94 > Author: Juergen Spitzmueller > Date: Fri Mar 9 13:30:52 2018 +0100 > > tex2lyx: chapterbib support Candidate for 2.3.2-staging. Jürgen signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Fix crash when citeengine is unknown.
Am Donnerstag, den 08.03.2018, 16:32 -0500 schrieb Richard Heck: > Question that popped up while looking at this > > Is it possible for more than one citeengine to be loaded by a > document at one > time? No. > If so, how (other than by editing the LyX file itself)? Assuming it > is not > possible, then is it OK to change BufferParams::cite_engine_ to a > std::string > (and simplify code elsewhere)? Yes, sure. I don't know why I didn't do that from the beginning. Possibly just an oversight when separating the cite engines from the modules. Jürgen > > Richard > signature.asc Description: This is a digitally signed message part
