[Bug 60170] New: Emacs zoom not fully working for ASCII vs non-ASCII, unicode
http://bugs.winehq.org/show_bug.cgi?id=60170 Bug ID: 60170 Summary: Emacs zoom not fully working for ASCII vs non-ASCII, unicode Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs@list.winehq.org Reporter: wineryyyyy@gmail.com Target Milestone: --- Distribution: --- Created attachment 81810 --> http://bugs.winehq.org/attachment.cgi?id=81810 Screenshot GNU Emacs 30.2 zoom not fully working for wine-11.15-ab0b3e25268 `M-x view-hello-file` shows most non-ASCII supporting zoom but not ASCII. `M-x describe-char` provides more details about each of the characters: character: λ (displayed as λ) (codepoint 955, #o1673, #x3bb) charset: unicode (Unicode (ISO10646)) code point in charset: 0x03BB script: greek Most Emacs modes mostly deal with ASCII only especially for dev purposes so zoom is broken for some of the most common modes including: - Dired - org-mode - magit - c-mode - ibuffer - shell - info Some more edge modes like eww (web browser) and image viewer support zoom. Most Emacs users will probably just use native vs Windows via wine but whatever is bugged may affect other apps so it provides a reliable reproduction. I've used Emacs to test other text/font related bugs that are still an enigma so hopefully progress for this bug will lead to solutions for those others. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #1 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81811 --> http://bugs.winehq.org/attachment.cgi?id=81811 WINEDEBUG=warn+all,err+all logs with 3 gaps between init, view-hello-file, and zooms 3 gaps between files: 1. Emacs init/open 2. M-x view-hello-file 3. Zoom ops 2 seems most relevant with fonts logs as my guess for which module may be bugged. Maybe lib deps external to wine need some resolves. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #2 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81812 --> http://bugs.winehq.org/attachment.cgi?id=81812 Screenshot view-hello-file for GNU Emacs 31.0.50 for Debian 13 for diff -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81829 --> http://bugs.winehq.org/attachment.cgi?id=81829 Screenshots emacs.exe (left) vs Emacs Debian 13 (right) for Arabic text/font scaling bugged Screenshots show `M-x describe-char` diffs between wine vs Debian 13 emacs for Arabic font render bug may be related to font/text scaling bug: - https://bugs.winehq.org/show_bug.cgi?id=57405#c3 - https://bugs.winehq.org/attachment.cgi?id=81828 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #4 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81831 --> http://bugs.winehq.org/attachment.cgi?id=81831 Screenshot Elisp code containing unicode ‘ zoomed/scaled but not for all other ASCII -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #5 from Stian Low <wineryyyyy@gmail.com> --- I'll test Windows 11 to see if harbuzz vs ftcrhb diffs may be part of the problem: - https://www.gnu.org/software/emacs/manual/html_node/elisp/Low_002dLevel-Font... emacs.exe via Wine: - arabic: - harfbuzz:-outline-Unifont-regular-normal-normal-mono-80-*-*-*-c-*-iso10646-1 - elisp unicode char: - harfbuzz:-outline-Liberation Mono-regular-normal-normal-mono-241-*-*-*-c-*-iso10646-1 (#x7D7) Emacs via Debian 13: - arabic - ftcrhb:-GOOG-Noto Naskh Arabic UI-regular-normal-normal-*-80-*-*-*-*-0-iso10646-1 - elisp unicode char: - ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x723) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Emacs zoom not fully |Emacs text/font |working for ASCII vs |zoom/scaling not fully |non-ASCII, unicode |working for ASCII vs | |non-ASCII, unicode -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81835 --> http://bugs.winehq.org/attachment.cgi?id=81835 Screenshots ASCII zoom/scaling working with arabic text for Window 11 (In reply to Stian Low from comment #5)
I'll test Windows 11 to see if harbuzz vs ftcrhb diffs may be part of the problem:
Screenshot shows harfbuzz overall working better for Windows 11 but there are some more minor diffs vs Debian 13 but regardless wine matching Win11 would be an improvement. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #7 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81836 --> http://bugs.winehq.org/attachment.cgi?id=81836 Screenshot showing Emacs eww (web browser) supporting zoom/scaling for both ASCII and non-ASCII (but still not fully working for wine) (In reply to Stian Low from comment #0)
Some more edge modes like eww (web browser) and image viewer support zoom.
Despite eww zooming/scaling some ASCII along with non-ASCII it is probably related to eww special handling for higher level HTML tags/wrappers because lowest level HTML ASCII raw text seems not to be zoomed like the arabic unicode similar to the other Emacs modes mentioned. Windows eww zooms/scales lowest level HTML ASCII along with non-ASCII same as Debian 13 Emacs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #8 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81837 --> http://bugs.winehq.org/attachment.cgi?id=81837 Screenshots winetricks corefonts working around ASCII not zooming/scaling with non-ASCII/unicode (In reply to Stian Low from comment #1)
Maybe lib deps external to wine need some resolves.
Are winetricks fonts as a workarounds considered fixed enough to close? Other issues are typically left open until wine provides a solution without winetricks but maybe fonts are considered an exception. Some languages text/font are still not rendered properly despite installing every winetricks font available but that's a separate bug because the block symbols in their place are scaled along with ASCII as expected. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source URL| |https://www.gnu.org/savanna | |h-checkouts/gnu/emacs/downl | |oad.html#nonfree --- Comment #9 from Ken Sharp <imwellcushtymelike@gmail.com> ---
Are winetricks fonts as a workarounds considered fixed enough to close?
Nope. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #10 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Ken Sharp from comment #9)
Nope.
Thanks for clarifying. Agreed. FSF/GNU Emacs teams consider Windows fonts a corruption worthy of warning so best to support most basic functionality without such dependencies: - https://directory.fsf.org/wiki/Wine It seems likely this bug is a duplicate of some earlier fonts bug but so I'll mark it if/when found. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #11 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81870 --> http://bugs.winehq.org/attachment.cgi?id=81870 Screenshots Windows Courier using bold to also barely support zoom for ASCII vs non-ASCII Emacs for Windows 11 defaults to Courier New which seems unavailable for vanilla wine so it falls back to Courier which seems to behave very similar to Windows except Windows bolds for zoom up until a point when non-ASCII characters become so big that ASCII becomes unbolded with results appearing very similar to emacs.exe via wine for the same high zoom level. Therefore not bolding ASCII for lower level zooms seems to be the only obvious inconsistency for Courier for wine vs Windows 11 which is very minor. Other fonts like Courier New and Tahoma support zoom for both ASCII and non-ASCII. Tahoma is available for vanilla wine like Windows and seems to handle zoom similarly but fairly messy as an alternative. I typically leave Emacs mostly default with few customizations so maybe its worth supporting Courier New for vanilla to achieve consistent default results with Windows 11. There are probably other fonts available for vanilla that look clean enough like Courier but also support zoom as a workaround without any winetricks as alternative workaround. Overall remaining issues for this bug should be considered very low priority if not practically closable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #12 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81872 --> http://bugs.winehq.org/attachment.cgi?id=81872 Screenshots showing Windows 11 Courier more clearly supporting 3 level of zoom in (In reply to Stian Low from comment #11)
Therefore not bolding ASCII for lower level zooms seems to be the only obvious inconsistency for Courier for wine vs Windows 11 which is very minor.
Correction regarding wine default Courier font only needing to add support for bold for zooms: Windows 11 Courier supports 3 levels of zoom in which is clearer for mostly ASCII modes shown in screenshots for dired and c-mode. Other fonts such as Courier New support much higher/lower zoom levels. Courier lacks support for the same 3 zoom levels out for Windows 11 so wine only needs to support 3 zoom in levels for Courier. Currently no zoom levels are supported so text always remains the same size. Courier also does not appear in the list for `M-x set-frame-font` which is the latest way to set fonts but Courier is available via options menu Set Default Fonts for legacy purposes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #13 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81873 --> http://bugs.winehq.org/attachment.cgi?id=81873 Screenshots `BPG Courier GPL&GNU` vs default Courier for emacs.exe supporting near equivalent of Windows 11 default Courier New Screenshots `BPG Courier GPL&GNU` vs default Courier for emacs.exe supporting near equivalent of Windows 11 default Courier New emacs.exe via wine `M-x set-frame-font` lists 2 options for Courier: -outline-BPG Courier GPL&GNU-regular-normal-normal-mono-*-*-*-*-c-*-iso10646-1 -outline-BPG Courier S GPL&GNU-regular-normal-normal-mono-*-*-*-*-c-*-iso10646-1 Both seem to support higher/lower zoom levels and closely resemble Courier New. If -outline-BPG Courier GPL&GNU were chosen by default then this bug may have never been opened. Windows 11 offers 4 options for Courier New for `M-x set-frame-font` but does not list just plain Courier same as wine.exe via wine so Options menu Set Default Font may be used instead. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60170 --- Comment #14 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #13)
Windows 11 offers 4 options for Courier New for `M-x set-frame-font` but does not list just plain Courier same as wine.exe via wine so Options menu Set Default Font may be used instead.
Correction: emacs.exe via wine Leaving open until Courier supports 3 zoom in levels but BPG Courier GPL&GNU without any winetricks workarounds makes this bug much lower priority. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla