Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cairo rendering fuzzy on horizontal bars #18

Closed
Atemu opened this issue May 5, 2021 · 5 comments
Closed

Cairo rendering fuzzy on horizontal bars #18

Atemu opened this issue May 5, 2021 · 5 comments

Comments

@Atemu
Copy link

Atemu commented May 5, 2021

Hi, I've been a happy user of mlterm for a while now but there's something bugging me with the font rendering:

Cairo:
image

Xft:

image

I'm not sure it comes across very well in the images (github does some sort of processing on them, the colors are a bit off) but horizontal bars are fuzzy in an inconsistent way. This is especially noticeable on the ===, es and Ts but also the [s.
(Ideally compare this by switching between the font renderers on your system in real time.)

Are you able to reproduce the bahaviour? I want to make sure it's not a packaging bug on my end.

Is that a Cairo bug perhaps? My Emacs and lxterminal are built against Cairo too though AFAICT (the latter through vte+pango) and do not exhibit this behaviour.

Unfortunately, simply using xft is not an option as it fails to display CJK characters.

Dotfiles: https://github.com/Atemu/dotfiles/tree/62cc068345cebd5346f4ead6f0a58efab2293a2f/.config/mlterm/
Nixpkgs: https://github.com/Atemu/nixpkgs/blob/22aaac9cbc6a472c0e68b86466b241d25aa051dc/pkgs/applications/terminal-emulators/mlterm/default.nix
Nixos-config: https://github.com/Atemu/nixos-config/blob/9e13cb6801af2714f820a8fed1d81401adeb5653/configs/HEPHAISTOS/default.nix
@arakiken
Copy link
Owner

arakiken commented May 7, 2021

Thanks.

Does this patch improve this issue? -> http://mlterm.sf.net/mlterm-3.9.1-fixcairostyle.patch
I'd like you to test it.

@Atemu
Copy link
Author

Atemu commented May 9, 2021

Looks flawless; regular text is indistinguishable from Xft with that patch. (Bold text looks different but that might be intentional)

Is CAIRO_FORCE_DOUBLE_DRAWING a parameter one should tweak on the packaging side somehow?

Btw, is Xft not displaying CJK characters a bug or is it an issue on my end?

Atemu added a commit to Atemu/nixpkgs that referenced this issue May 10, 2021
@Atemu
mlterm: add fixcairostyle patch
1400baa 
From arakiken/mlterm#18 (comment)
@arakiken
Copy link
Owner

Hi,

I don't recommend defining CAIRO_FORCE_DOUBLE_DRAWING.
This is because the glyph width of some fonts is different between regular style and bold style, in which case it is necessary to draw glyphs of the bold style font one by one to fit the normal style font width, and the screen drawing gets slow.

It is necessary to use a font which includes CJK glyphs or to specify it as follows in ~/.mlterm/aafont manually in order to show CJK characters with Xft.
ISO10646_UCS4_1_FULLWIDTH=(Font Name)

mlterm with cairo searches alternative fonts automatically if it doesn't find glyphs for some characters, but mlterm with Xft doesn't support it for now.

Regards,

@arakiken
Copy link
Owner

Sorry, I misunderstand.
It is not necessary to define CAIRO_FORCE_DOUBLE_DRAWING with cairo-1.8.0 or later.
I'll undefine CAIRO_FORCE_DOUBLE_DRAWING by default.

@Atemu
Copy link
Author

Atemu commented Jun 13, 2021

Fixed as of 96ea847, thank you!

@Atemu Atemu closed this as completed Jun 13, 2021
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jan 17, 2022
@tsutsui
mlterm: update to 3.9.2.
c43c68a 
pkgsrc changes:
* switch MASTER_SITES to GitHub
* use GTK3 instead of GTK2
* remove local patches integreated into upstream (#5)

Upstream changes (noted in doc/en/ReleaseNote):

ver 3.9.2
* Support Fcitx5.
* Support GTK4 for mlconfig. (./configure --with-gtk=4.0)
* Support CSI > Ps q (XTVERSION). (Response: DCS>|mlterm(3.9.2)ST)
* Add "MOSH_UDP_PORT" environmental variable to specify UDP port or port-range
  to communicate with a mosh server.
* Add INSERT_CLIPBOARD shortcut key.
  (arakiken/mlterm#19)
* Add --fk / format_other_keys option (equivalent to "formatOtherKeys" of xterm), and
  change the default format of the escape sequence with modifyOtherKeys from
  CSI Ps; Ps u to CSI 27; Ps; Ps ~.
* Add --with-iconv, --disable-daemon, --disable-split and --disable-zmodem
  options to ./configure script.
* Add vte 0.66 API symbols to libvte compatible library.
* Show server list dialog at startup on Android.
* It is deprecated to use "mlterm" as the value of termtype / -y option.
* 'termcap' config file stops to accept multiple terminal types concated by '|'
  (e.g. xterm|xterm-256) as key.
* Arabic ligatures (U+644-U+622, U+644-U+622, U+644-U+625, U+644-U+627) occupy
  two logical columns instead of one even if --dyncomb option isn't specified.
* KBD_INPUT_NUM and MOUSE_INPUT_NUM environmental variables (for mlterm-fb)
  accept multiple device numbers by "<num>,<num>".
* Show "Config: key=value" only if shortcut keys whose format is
  "proto:(echo)key=value" is pressed.
* Merge patches:
  arakiken/mlterm#5.
  arakiken/mlterm#9.
  arakiken/mlterm#12.
  arakiken/mlterm#22.
* Bug fixes:
  Fix arakiken/mlterm#15.
  Fix arakiken/mlterm#18.
  Fix arakiken/mlterm#24.
  Fix arakiken/mlterm#28.
  Fix failure of restarting mlterm on Android. (Enbugged at 3.9.1)
  Fix segfault if mlterm screen with -t option goes outside of the display.
  Fix emoji glyphs becoming too large with cairo.
  Fix corrupt value of "word_separator" option which mlconfig outputs.
  Fix incompatibility with xterm in pressing Shift + a-z keys etc if modifyOtherKeys is 1.
  (arakiken/mlterm#21)
  Fix segfault in opening a new roxterm tab with libvte compatible library on wayland.
@hramrach hramrach mentioned this issue Feb 24, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@arakiken @Atemu