bugGNU Octave - Bugs: bug #55958, Incorrect symbolic dispay on macOS...

 
 

bug #55958: Incorrect symbolic dispay on macOS due to default Monaco font

Submitter:  None
Submitted:  Tue 19 Mar 2019 09:16:33 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Need Info Assigned to:  None
Originator Name:  ZM Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 4.4.0
Operating System:  * Mac OS Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 23 Mar 2019 06:28:35 PM UTC, comment #11: 

Indeed, the code in question is in ressource_manager. However, I have tested different apporoaches in order to get the fixed font which is currently configured for the window manager but without success. It seems that the currently used method as well as  QFontDatabase::systemFont(QFontDatabase::FixedFont) only provides the general default monospaced font but not the currently configured.

Torsten Lilge <ttl>
Group Member
Fri 22 Mar 2019 05:47:18 PM UTC, comment #10: 


> it had no apparent effect


Ok, I think Octave is querying the defaults on its own and passing it down to qterminal then.

Does setting "OCTAVE_DEFAULT_FONT=Menlo" in the environment before starting Octave (with ~/.config/octave deleted) work for you? If it does, then libgui/src/resource-manager.cc is where this is done.

On my Debian system, it also picks a bad default, strangely it doesn't use my Fontconfig preferences for Monospace, it instead picks "DejaVu Sans Mono". If I set "OCTAVE_DEFAULT_FONT=Noto Mono" in my environment then it works, and that value is written to all of the font settings in qt-settings or octave-gui.ini.

Mike Miller <mtmiller>
Group Member
Fri 22 Mar 2019 12:18:03 AM UTC, comment #9: 


> You're the resident expert on all things macOS now


Aw, you flatter me!

Andrew Janke <apjanke>
Fri 22 Mar 2019 12:17:08 AM UTC, comment #8: 

Well: file #46607 – I did the naive thing and just changed the font face and size in that `#ifdef Q_OS_MAC` section, and it had no apparent effect. When I deleted ~/.config/octave and fired up ./run-octave from the build directory, it still used Monaco 10 as the default font for the Command Window and Editer.

Maybe it's getting those defaults from somewhere else, and this section just applies to the defaults for the embedded qterminal widget object, which are themselves immediately overriden by the application-level preferences, which get their defaults from some other location.

> if we ever do try to reconcile with that, maybe we could try to link with qtermwidget as a library?


That might make sense. On macOS, it's not hard to install; I've already got a Homebrew formula for it – https://github.com/octave-app/homebrew-octave-app/blob/master/Formula/qtermwidget.rb – and it's available as a package in Debian – https://packages.debian.org/search?searchon=sourcenames&keywords=qtermwidget – and Ubuntu – https://packages.ubuntu.com/source/xenial/qtermwidget. So taking it as a library instead of bundled source sounds maybe feasible to me. It's just a question of whether the recent distro releases have picked up a new-and-good-enough version of QTermWidget for your purposes.

Andrew Janke <apjanke>
Thu 21 Mar 2019 10:48:24 PM UTC, comment #7: 

Retitling this since it really isn't about the symbolic package now.

You're the resident expert on all things macOS now, so we'll defer to you, if you think a patch to change the font is safe and helpful, let's do that. If you have a tested patch I'll be happy to push it to stable for you.

Since qterminal has diverged significantly, I guess it doesn't really matter whether we try to stay as close to the orignal as possible. I'm aware of the upstream projects, and if we ever do try to reconcile with that, maybe we could try to link with qtermwidget as a library?

Mike Miller <mtmiller>
Group Member
Thu 21 Mar 2019 10:01:00 PM UTC, comment #6: 

Heh. I've already talked upstream into switching to Menlo: https://github.com/lxqt/qtermwidget/pull/259/files. I'll ask them about 12 point, too.

Upstream for the qterminal widget has diverged significantly from what we have in Octave. Support for the embedded widget is now the QTermWidget project - https://github.com/lxqt/qtermwidget - and qterminal is a client project of it that uses QTermWidget to build a standalone terminal emulator app. So we cannot import upstream code directly, and we're diverged enough we may as well make small changes in our fork as suits us.

My recommendation is just to replace that "Monaco"/11 point under Q_OS_MAC with "Menlo"/12 point. I'd go so far as to patch that change into the upcoming Octave.app 5.1.0 release.

There have been a lot of changes (and ostensibly improvements) since Octave forked qterminal, but macOS support there has lagged recently. I'm currently working with the QTermWidget/QTerminal folks to get macOS support back up to speed. (All of which I'm doing because I want to fix bug #55913.) (I know I'm harping on Mac stuff, but that is a supported Octave platform, right?) After that's working, maybe we can consider doing a re-import from upstream.

Andrew Janke <apjanke>
Thu 21 Mar 2019 09:42:53 PM UTC, comment #5: 

Hmm, looks like we inherited it from (an ancient version of?) qterminal:


#ifdef Q_OS_MAC
    QFont font = QFont("Monaco");
    font.setStyleHint(QFont::TypeWriter);
    font.setPointSize(11);
#else
    QFont font = QFont("Monospace");
    font.setStyleHint(QFont::TypeWriter);
    font.setPointSize(10);


https://hg.savannah.gnu.org/hgweb/octave/file/51414d51a973/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp#l64

If this is obsolete should we update this in Octave? Is there updated code we can import from the upstream qterminal project?

Mike Miller <mtmiller>
Group Member
Thu 21 Mar 2019 09:12:19 PM UTC, comment #4: 


> Is the font chosen a macOS app packaging issue, or just a user configuration issue?


From what I understand, Monaco 10 point is the default that Octave itself chooses on macOS. (Maybe inheriting from Qt's defaults?) The Octave.app packaging does not make any changes to font selection or user preferences.

Maybe it should, though: Monaco 10 point is awfully small and hard to read, even on a Retina screen. I think it might be a relic of an earlier time when effective pixel sizes were slightly larger. Indeed, the first thing I do when I install Octave on a Mac myself is to change its font to Menlo 12 point in both Command Window and Editor. And other modern terminal programs, like Mac's own Terminal.app, use Menlo as the default, and I believe they use 12 point as the default size. IIRC, most editors use 12 point default, too.

If there's a decent supported way for the Octave packagers to change these defaults, I'd be happy to have Octave.app switch to Menlo 12 as the default. (Menlo is a macOS system font, so it's guaranteed to be available on all Mac machines.)

And maybe you could consider changing the default in core Octave for future releases?

Sorry about the inconvenience here. This is probably something that should have occurred to us at Octave.app.

> There are no instructions on https://wiki.octave.org/Octave_for_macOS on how to go about upgrading.


There's no upgrader built in to the app. Just download the new version from http://octave-app.org/Download.html, install it manually, and delete the old version if you'd like. (You can keep both versions installed side-by-side if you want, so you can try out the new version before committing to it.)

There is a 5.1.0 beta available on the Developer Downloads page, if you want to try it out for testing here. http://octave-app.org/Developer-Downloads.html. Be warned - we are seeing stability problems with this release/build, so I wouldn't upgrade to it as your main Octave just yet.

Andrew Janke <apjanke>
Thu 21 Mar 2019 08:49:53 PM UTC, comment #3: 

@apjanke Is the font chosen a macOS app packaging issue, or just a user configuration issue?

Mike Miller <mtmiller>
Group Member
Wed 20 Mar 2019 08:50:01 PM UTC, comment #2: 

Hi,

The font was the problem! It was on Monaco@10pt and very hazy.

I switched to Menlo@12pt and it's great now.

I am running it on MAC OS and downloaded the pre-made dmg bundle file, since it was less of a trial to install.

There are no instructions on https://wiki.octave.org/Octave_for_macOS on how to go about upgrading.

Any assistance would be greatly appreciated.

Thank you!

Z. M. <zmarantz>
Wed 20 Mar 2019 06:16:05 AM UTC, comment #1: 

Thank you for your bug report. I can't reproduce this on my system. The Unicode rendering of symbolic fractions is likely to depend on a few factors, including the font you have configured Octave to use, the version of the symbolic package you have installed, and the versions of Python and SymPy that are used.

What font is Octave using in the command window? Can you try different fonts to see if that helps? What is the full output of 'sympref diagnose'? Are you able to upgrade to Octave 5.1.0 to see if there is any difference?

Mike Miller <mtmiller>
Group Member
Tue 19 Mar 2019 09:16:33 PM UTC, original submission:  

Dear Maintainers,

I run the following code in Octave 4.4.0:

syms t omega A
x = A*t;
Xsym=int(x*exp(-j*omega*t),t,-1/2,1/2)

The resulting output looks like in the attached file, even after using pretty().

The issue is that the negative sign in front of the first parenthetical fraction can be barely seen because is blends in with the division bar.

All that's needed is a small space to be added or to include the negative sign in the numerator explicitly. 

(I searched for this problem everywhere, but could find no solution for it.)

Thank you,
Z

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46607:  octave-menlo12-mac-default-naive.patch added by apjanke (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by zmarantz (Posted a comment)
  • -email is unavailable- added by cbm
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-22 apjanke Attached File- Added octave-menlo12-mac-default-naive.patch, #46607
    2019-03-21 mtmiller Summary[octave forge] (symbolic) Incorrect symbolic dispay Incorrect symbolic dispay on macOS due to default Monaco font
    2019-03-21 mtmiller Carbon-Copy- Added apjanke
    2019-03-20 cbm Carbon-Copy- Added cbm
    2019-03-20 mtmiller StatusNone Need Info
        SummaryIncorrect symbolic dispay [octave forge] (symbolic) Incorrect symbolic dispay
    2019-03-19 None Attached File- Added Screen Shot 2019-03-19 at 5.05.17 PM.png, #46585

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code