From sgougeon at free.fr Fri Dec 6 10:33:41 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 10:33:41 +0100 Subject: [Scilab-Dev] Issue with unicode exponents In-Reply-To: <3ce53001-eb42-d831-30f3-022f12048aa5@free.fr> References: <7583fd5c-9f93-2ea6-1b33-705d9bcdafb6@free.fr> <6b697333-91d2-edb7-4942-0327b968b27b@scilab-enterprises.com> <3ce53001-eb42-d831-30f3-022f12048aa5@free.fr> Message-ID: <8c2be7c0-70ca-8602-82fb-5360e41d9c4d@free.fr> Le 28/11/2019 ? 23:35, Samuel Gougeon a ?crit?: > Hello Antoine, > > Le 28/11/2019 ? 23:17, Antoine ELIAS a ?crit?: >> Hello Samuel, >> >> I'm agree with you about the issue. >> I will try to find a way to change the console properties inside >> binary like when we change color in nw mode ( W/B vs B/W ) > > > Great. > >> >> But I does not show trouble with 2 or 3 and others superscript numbers. >> >> >> >> With this configuration > > > Neither does it for me, provided that this setting is done /before/ > running Scilab. > Humm, mainly provided that the code page was changed to 65001 before this font setting. > By the way, /Lucida console/ is much UTF-8-richer than /Consolas/ (you > may test the text below in Scinotes with both fonts, and compare their > renderings), and superscripts 0,4-9 are bigger. > I don't know what tests i did, but on my computer as well, superscripts are displayed with /Consolas/, but NOT with /Lucida Console/, that looks less rich on this aspect. But much poorer than /DejaVue Mono/, that however is not in the list of default TrueType fonts of Windows (7) computers, contrarily to /Consolas/ and /Lucida console/. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dkmibiggcabpfopa.png Type: image/png Size: 1221 bytes Desc: not available URL: From sgougeon at free.fr Fri Dec 6 10:46:16 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 10:46:16 +0100 Subject: [Scilab-Dev] Issue with unicode exponents In-Reply-To: <63bd6b6c-7adf-d30c-fa41-8b5c88c84033@scilab-enterprises.com> References: <7583fd5c-9f93-2ea6-1b33-705d9bcdafb6@free.fr> <6b697333-91d2-edb7-4942-0327b968b27b@scilab-enterprises.com> <3ce53001-eb42-d831-30f3-022f12048aa5@free.fr> <63bd6b6c-7adf-d30c-fa41-8b5c88c84033@scilab-enterprises.com> Message-ID: Le 29/11/2019 ? 00:36, Antoine ELIAS a ?crit?: > > > Le 28/11/2019 ? 23:35, Samuel Gougeon a ?crit?: >> Hello Antoine, >> >> Le 28/11/2019 ? 23:17, Antoine ELIAS a ?crit?: >>> Hello Samuel, >>> >>> I'm agree with you about the issue. >>> I will try to find a way to change the console properties inside >>> binary like when we change color in nw mode ( W/B vs B/W ) >> >> Great. >> > I hope https://codereview.scilab.org/#/c/21143/ will help. It great to force the code page in the binaries. That's a pre-requisite to then be able to set a TrueType font and to take it actually working in the terminal. So i will abandon my commit setting the code page in the batch. Thanks. But always forcing the font to /Consolas/ without testing -- if possible -- if a TrueType font is already set instead of Raster, would reset any richer user setting like for /DejaVu Mono/. This could be easily blocking. So, if the binary does not detect the current font and does not test if it's already a TrueType UTF-8 one or not, the font should not be forced. It then will be easy to add some short indications in the documentation to drive users to change the font to use a rich one required by the user locale. When we set the font of the terminal on Windows, it is saved in the registry, and then all forthcoming opened terminals use the same relevant font. So it's only a one-time operation. Samuel >> %chars.greek.lower = "??????????????????????????????????????????"; >> %chars.greek.upper = "???????????????????????????"; >> %chars.maths.logical = "???????????????"; >> %chars.maths.set = "??????????????????????"; >> %chars.maths.comparisons = "??????????????????"; >> %chars.maths.operators = "???????????????????????????"; >> %chars.maths.integdiff = "????????????"; >> %chars.maths.geometry = "????????????????"; >> %chars.maths.misc = "??????????"; >> %chars.arrows.base = "???????????????????????"; >> %chars.arrows.thick = "????????????????"; >> %chars.symbols = "?????????????????????????"; >> %chars.stars = "??????????????????"; >> //%chars.currencies = "?$??????????"; >> >> %chars.lang.french = "??????????????????????????????"; >> %chars.lang.japanese.hiragana.a = "?????????? ?????"; >> %chars.lang.japanese.hiragana.i = "??????? ?? ?????"; >> %chars.lang.japanese.hiragana.u = "????????? ?????"; >> %chars.lang.japanese.hiragana.e = "??????? ?? ?????"; >> %chars.lang.japanese.hiragana.o = "????????????????"; >> %chars.lang.russian.upper = "?????????????????????????????????"; >> %chars.lang.russian.lower = "?????????????????????????????????"; -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 6 11:32:31 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 11:32:31 +0100 Subject: [Scilab-Dev] Issue with unicode exponents In-Reply-To: References: <7583fd5c-9f93-2ea6-1b33-705d9bcdafb6@free.fr> <6b697333-91d2-edb7-4942-0327b968b27b@scilab-enterprises.com> <3ce53001-eb42-d831-30f3-022f12048aa5@free.fr> <63bd6b6c-7adf-d30c-fa41-8b5c88c84033@scilab-enterprises.com> Message-ID: Le 29/11/2019 ? 12:10, St?phane Mottelet a ?crit?: > > Hello, > > Altough I am the author or this patch, I find this may be a bit too > early to make the hypothesis that Scilab would be systematically > launched in an environment that allows Unicode chars. > This hypothesis is not needed to go on with Unicode in terminal modes and improve things about this. On windows,? including the code page setting in the Scilab binary as proposed by Antoine is a first interesting and required step. > This could be, at least, a rendering option (BTW we need an unified > way of customizing display in the preferences tab). > Allowing and even using an UTF-8 font in Scilab NW and NWNI modes should not be an option. It should be the default. > However, using a one line display seems an improvement to me, it > allows a much better rendering of polynomials and rationals (see > https://codereview.scilab.org/#/c/21142/). > Because exponents are really too small, and because the console can't be zoomed interactively with a shortkey and the mouse wheel, in term of readability, the current status is clearly the best: --> (1-%z).^(0:4) ?ans? = ????????????????????? 2??????????? 2?? 3??????????? 2 3?? 4 ?? 1?? 1 -z?? 1 -2z +z??? 1 -3z +3z? -z??? 1 -4z +6z -4z? +z In term of compacity, indeed using Unicode exponents is a good idea. Unfortunately, with some fonts like Consolas, all exponents are so small wrt to the base font size that i use to use that some of them? become hardly distinguishable. --> (1-%z).^(0:4) ?ans? = ?? 1?? 1 -z?? 1 -2z +z??? 1 -3z +3z? -z??? 1 -4z +6z? -4z? +z? But this can be worked around by increasing the font size (from Monospaced 14 to 16, for me). > Maybe a intermediary step would be to use a hat notation, e.g. > > --> p=(1+%i+%s)^7 > > p = 8-8i -56is -(84+84i)s^2 -140s^3 -(70-70i)s^4 +42is^5 +(7+7i)s^6 +s^7 > Definitively not. It turns crowdy. Keeping the current 2-line display would be better, even if it's less compact vertically. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 6 11:38:37 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 11:38:37 +0100 Subject: [Scilab-Dev] Issue with unicode exponents In-Reply-To: References: <7583fd5c-9f93-2ea6-1b33-705d9bcdafb6@free.fr> Message-ID: Le 29/11/2019 ? 13:05, St?phane Mottelet a ?crit?: > > BTW, under Windows, none of the console mode seems to support simple > accented characters : > > --> disp "?" > > ??? > > The super/subscript problem is just a small part of this more general > issue. > Yes, sure. This is the point of the long standing reported bug mentionned in my first message. From sgougeon at free.fr Fri Dec 6 11:56:01 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 11:56:01 +0100 Subject: [Scilab-Dev] Issue with unicode exponents In-Reply-To: <86641650-2de7-021d-633b-20d752bee0a8@utc.fr> References: <7583fd5c-9f93-2ea6-1b33-705d9bcdafb6@free.fr> <86641650-2de7-021d-633b-20d752bee0a8@utc.fr> Message-ID: <5d00e78c-17fa-da07-8dad-f3ddf8261205@free.fr> Le 29/11/2019 ? 13:20, St?phane Mottelet a ?crit?: > > Sorry for these multiple answers, but after thinking about this issue, > I arrived at the conclusion that we should consider the use of unicode > subscript only as a failsafe solution. In GUI mode (Java console), we > should use html output. This will solve the problem of readability of > exponents and allow many interesting stuff, such as outputing links, ... > This was possible in some master (in 5.3 or 5.4?), when Calixte developed the scimax module. In the scimax home page, there were some examples using and rendering latex expressions in the console, including loading images (like the puffin :-) with \includegraphics. And it nicely worked, indeed. Unfortunately, this feature was removed. AFAIK and remember, it set some security issue. Being able to style and/or make some output active would be very useful, indeed. For instance to * use different colors to display instructions lines, results, warnings, and error messages (reported bugs) * set internal or external hyperlinks * etc Whatever is the implementation, some effects would have to be managed to keep clean and clear the history, the diary(), and may be other existing features related to the console inputs or/and outputs. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Mon Dec 23 10:57:21 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 23 Dec 2019 10:57:21 +0100 Subject: [Scilab-Dev] uimenu.callback_type == -2 ? In-Reply-To: <8e3816d7-442a-bf1d-6e3f-1345cc38081e@free.fr> References: <8e3816d7-442a-bf1d-6e3f-1345cc38081e@free.fr> Message-ID: <71bd24bb-0288-617d-889f-801ed7f8008c@free.fr> Le 07/09/2019 ? 13:32, Samuel Gougeon a ?crit?: > > Hello, > > While i wasupdating the uimenu_properties page > , noticeably to document .callback_type, > i noticed that one of the Figures submenu has a .callback_type set to > -2 (see below). > I have found nothing in the uicontrol doc about the meaning of this value. > > Would you know? what it is, to interpret .callback? > > Thanks > Samuel > > --> get(0).showhiddenhandles = "on"; > --> gcf().children(4).children(1) > ?ans? = > > Handle of type "uimenu" with properties: > ======================================== > Parent: uimenu > Children: [] > Enable = "on" > Foregroundcolor = [0,0,0] > Label = "&Rotation 2D/3D" > Handle_Visible = "off" > Visible = "on" > Callback = "set(get_figure_handle([SCILAB_FIGURE_ID]), > ''info_message'', ''Right click and drag to rotate.'')" > Callback_Type = *-*2 > Checked =? "off" > Icon =? "transform-rotate" > Userdata = [] > Tag = "" > Le 16/09/2019 ? 19:39, tom.kreisel@*.de a ?crit : > Hi Samuel, > > I was also struggling with callback_type so I can maybe give some hints from a programmers perspective. > Since I am new to Scilab I played around with the master build and the xcos debug gui, which was not working until I added the callback_type property 10 to the source code. > I found in the code: > /** >? * Abstract class to manage all callbacks. >? * >? * @author Bruno JOFRET >? */ > public class CallBack { > >???? /** >????? * Unmanaged command type constant >????? */ >???? public static final int UNTYPED = -1; >???? /** >????? * Scilab instruction command type constant >????? */ >???? public static final int SCILAB_INSTRUCTION = 0; >???? public static final int SCILAB_NOT_INTERRUPTIBLE_INSTRUCTION = 10; >???? /** >????? * C or Fortran function type constant >????? */ >???? public static final int C_FORTRAN = 1; >???? /** >????? * Scilab function type constant >????? */ >???? public static final int SCILAB_FUNCTION = 2; >???? public static final int SCILAB_NOT_INTERRUPTIBLE_FUNCTION = 12; >???? /** >????? * Scilab function type constant (not trapped by scilab event listeners) >????? */ >???? public static final int SCILAB_OUT_OF_XCLICK_AND_XGETMOUSE = -2; >???? /** >????? * Java function type constant >????? */ >???? public static final int JAVA = 3; >???? /** >????? * Java function type constant (not trapped by scilab event listeners) >????? */ >???? public static final int JAVA_OUT_OF_XCLICK_AND_XGETMOUSE = -3; > >???? /** >????? * Scilab instruction without GCBO setting (used in case of pause/resume/abort) >????? */ >???? public static final int SCILAB_INSTRUCTION_WITHOUT_GCBO = 4; > > [...] > > so -2 means SCILAB_OUT_OF_XCLICK_AND_XGETMOUSE: > > If this type is used, the actionPerformed method of the ScilabCallbackClass is overriden to just call the callback: > /** >????? * Callback Factory to easily create a callback >????? * just like in scilab. >????? * WARNING : this callback will be ignored by xclick & xgetmouse >????? * @param command : the command to execute. >????? * @return a usable Scilab callback >????? */ >???? public static ScilabCallBack createOutOfXclickAndXgetmouse(String command) { >???????? return (new ScilabCallBack(command) { > >???????????? private static final long serialVersionUID = -7286803341046313407L; > >???????????? public void callBack() { >???????????????? Thread launchMe = new Thread() { >???????????????????? public void run() { > InterpreterManagement.putCommandInScilabQueue(getCommand()); >???????????????????? } >???????????????? }; >???????????????? launchMe.start(); >???????????? } > >???????????? /** >????????????? * To match the standard Java Action management. >????????????? * @see java.awt.event.ActionListener#actionPerformed(java.awt.event.ActionEvent) >????????????? * @param e The event that launch the callback. >????????????? */ >???????????? public void actionPerformed(ActionEvent e) { >???????????????? callBack(); >???????????? } >???????? }); >???? } > > The usual implementation uses a GlobalEventWatcher, I guess this implements the xclick and xgetmouse features. > >??? /** >????? * To match the standard Java Action management. >????? * @see java.awt.event.ActionListener#actionPerformed(java.awt.event.ActionEvent) >????? * @param e The event that launch the callback. >????? */ >???? public void actionPerformed(ActionEvent e) { >???????? if (!GlobalEventWatcher.isCatchingCallback()) { >???????????? callBack(); >???????? } else { >???????????? if (this.callback.getCommand() != null) { > GlobalEventFilter.filterCallback(this.callback.getCommand()); >???????????? } >???????? } >???? } > > so if you use -2 as type, xclick and xgetmouse listener will not be informed of your mouseclick. > > there are also other integers not mentioned in the docu. > > Would have liked to post this into the list, but currently the server rejects my email address... > > Hope this might be useful.. > > KR Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppggbishop at gmail.com Mon Dec 30 11:52:35 2019 From: ppggbishop at gmail.com (Peter Bishop) Date: Mon, 30 Dec 2019 03:52:35 -0700 (MST) Subject: [Scilab-Dev] What is the xcos alternative to WFILE_F? Message-ID: <1577703155908-0.post@n3.nabble.com> In the XCOS environment, WFILE_F was deprecated in 5.5.2 and removed in 6.0.0 This seems to be a VERY backward step as it makes it very difficult (impossible?) to generate ASCII output files that are readable/importable by other tools (e.g. Excel, Perl, Python) 5.5.2 tells me to use WRITEC_F instead - but this block lacks any option for generating ASCII formatted If there is a standard mechanism for generating ASCII output *within XCOS*, please explain how this can be done. If there is no facility for this, I cannot see myself ever using v6. -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From sgougeon at free.fr Mon Dec 30 17:59:18 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 30 Dec 2019 17:59:18 +0100 Subject: [Scilab-Dev] What is the xcos alternative to WFILE_F? In-Reply-To: <1577703155908-0.post@n3.nabble.com> References: <1577703155908-0.post@n3.nabble.com> Message-ID: <43e4b068-7109-f7db-e28f-b347ba8afc6b@free.fr> Hello devs, Le 30/12/2019 ? 11:52, Peter Bishop a ?crit?: > In the XCOS environment, WFILE_F was deprecated in 5.5.2 and removed in 6.0.0 > > This seems to be a VERY backward step as it makes it very difficult > (impossible?) to generate ASCII output files that are readable/importable by > other tools (e.g. Excel, Perl, Python) > > 5.5.2 tells me to use WRITEC_F instead - but this block lacks any option for > generating ASCII formatted > If there is a standard mechanism for generating ASCII output *within XCOS*, > please explain how this can be done. > > If there is no facility for this, I cannot see myself ever using v6. This issue has been reported as bug 14625 . Some question about the relevance of this undiscussed removal arose shortly after the block was declared obsolete, in 2012: http://mailinglists.scilab.org/Scilab-users-TR-WRITEC-f-amp-WFILE-f-tt4025217.html No anwser was provided by developers. And another one in 2015: http://mailinglists.scilab.org/How-to-use-writec-f-block-in-xcos-tt4032501.html Still without answer. IMO, unless some how-to explanations / answers / rationale for this removal are shortly provided, the block should be restored, and its obsolescence canceled. Indeed, WRITEC_f is a fake replacement. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: