-
Notifications
You must be signed in to change notification settings - Fork 442
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.
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
📌MacType needs your help #553
Comments
The Wizard appears to be decently good to me. I don't think it needs any rewriting. For the Tuner, is it possible to monitor MacType.ini and the After that, it enables MacType enthusiasts to write their own "tuner" application, which provides better interface to edit the .ini files. Since the changes are automatically reloaded, the "tuner" application has no need to offer a preview window, which significantly reduces the technical requirements for the programmers, yet still serves good user experience. |
Monitoring a file and reload on change is not something hard to implement. However, it would be hard to sync all the switches and trackers on reload. I'm thinking of adding another mode where users can type in a built-in editor freely and the preview windows will reflect what the profile would look like simultaneously. |
This is a typical way of implementation. It is OK if the full preview feature is hard to implement. On partial preview versus full preview, I have a VS extension which allows users to modify syntax highlight settings offers preview window. The scenario is somewhat similar to the one in MacType Tuner. However, the most intuitive way is to present the effects on the whole editor, where various syntax highlighters are working and the ultimate effects are demonstrated. Thus the users of my VS extension can not only see their changes immediately on the preview window, but also on the editor window, where they can then observe the overall effects. The full preview is extremely useful and helpful since the user can switch to other windows and immediately see how his rendition settings will come. I am sorry that I don't know about the implementation of MacType, and it is so difficult to "sync all the switches and trackers on reload". |
I was thinking long long long ago about a so-called debugging mode where mactype disables all the cache and hot reload the profile on-the-fly so that it can demonstrate what the final result looks like in real-time. The problem is that:
So I eventually give up the idea. |
You don't have to abandon the cache. The slowness makes sense. Full preview does not essentially mean to be real time preview. Problem 3, 4 are some problems. But they are irrelevant to the full preview. |
If what you want is to reload the profile without unloading and loading the mactype, the "Restart" item in the context menu of the mactray is what all you need. Replacing font is always dangerous. The problem is we don't know how dangerous it is until we apply it... |
The Wizard looks and works fine, the only problem with it is it's difficult to maintain (Delphi). These are good ideas, and good ideas are certainly a big way of helping! What I'm looking for also is people who can / will help with programming, UX, translating, testing, etc. |
Anyone who would like to write a new wizard is totally welcome and possible. The interface current wizard used to generate thumbnails is open source. All the loading modes implementations are not secret either. The reason I didn't publish the source of the wizard is that it relays on my private library and some modified commercial components and, it is a very early product of mine. It is so badly written that I'm not willing to do any large scale work on it. The popular framework electron allows you to make beautiful and feature-rich applications which is great. However, it is way too big that it is sort of against the principle of MacType. |
Hi! Well it looks like Microsoft is up to its old tricks... They've made some changes in Notepad.exe; exactly what I'm not sure... but in the newest version released with Insider's Build 18963 the text in the edit window as well as the menu items themselves are not being rendered with MacType. I did some experimenting and found that the new Notepad's text and menus will not render at all if using Registry mode. However when running in Services mode the text will render, the menus as well, but the cursor must first be hovered across the menu items or the whole window minimized then restored. In MacTray mode the rendering seemed to work sometimes, but not others. This was true in both Stand Alone and Compatibility options. I saved a prior copy of Notepad from Build 18941 that still functions properly with all text rendered by MacType. See below for samples of both, as you can see the difference is pretty obvious. I also included the only blurb Microsoft provided in the Insider's blog about the new Notepad, although there's no mention of any change in how text is handled... Maybe you guys can make sense of it... 😁 |
I think they have changed it to a metro app or a win32 transcoded UWP app which is, according to issue #494, not fully supported. |
@snowie2000, Interesting... crazy how they have so many different ways to do the same thing (open apps, render type, etc.). I guess I'll stick with my workaround of using an earlier "unbroken" version of Notepad. Any hope that this odd type of app will be supported in future MacType releases? It'd be great if it were, especially if Windows starts to use this scheme for more apps in the future... 😉 |
@snowie2000 @ChicoThorn I think Microsoft's CEO Satya Nadella will move towards Metro for everything, and eventually deprecate the old systems in Windows (and other products). It makes sense from a business point of view |
That means we need to figure out how the metro processes are spawned internally. |
@sammilucia and @snowie2000. — I'm baffled as to why the new Notepad can be rendered by MacType in Service mode, but not in Registry mode. In my mind that would indicate that the necessary bits to make it work are present, but for some reason aren't being invoked in Registry mode... ? Is this a fair assumption? ...and if it can work in Service mode then it also seems there must be a way to get it to work in Registry mode as well. Why am I so stuck on Registry mode? It seems to be the best and most complete way to enjoy MacType's rendering throughout the entire UI, without any unpleasant non-rendering surprises (that is until this new Notepad showed up on the scene). In Registry mode I don't have to fuss with hovering over a type element to invoke MacType's rendering (as is the case with several apps and programs when in Service mode; i.e., Task Manager, and the new Notepad). Registry mode's more seamless experience allows me to forget about font rendering issues and to focus on my work. Any chance that maybe some tinkering would get Registry mode to work with the new Notepad? 😃 |
@ChicoThorn it could be that the new Notepad has code injection protection. Registry mode uses AppInit_DLLs which is not a recommended method by Microsoft. MS are trying to make their platform more secure so it would make sense if they stop supporting AppInit_DLLs as an educated guess. Registry mode also won't work if you have Secure Boot enabled (and we recommend you do) - for the same reasons. Technically Service and Tray modes are the OS friendly ways to implement the kind of integration MacType does. (But yes as you say - not quite as complete.) @snowie2000 and I threw around the idea of implementing an API for MacType, so other software could choose to support MacType |
@sammilucia Ahhh... interesting about the AppInit_DLLs ... that explains a LOT! Basically I really like the Service mode too (except for the sometimes hovery-over-the-text-to-get-it-to-render thing). I've been running it about half and half the past week trying to settle on one or the other. But I'm going to do some screenshot comparisons to see if there's a real difference or just my imagination (...and I've been known to have an overactive imagination, so testing is essential, lol! 😁) |
@sammilucia, @snowie2000 — Hi! 😀 So after many screenshots I came to the following conclusions: Registry mode renders everything in the UI really well EXCEPT the new Notepad. Service mode renders everything in the UI really well EXCEPT some alert windows (UAC and registry warnings), and that annoying hover-first-see-rendering-after thing that happens in new Notepad and in Task Manager. So I use Notepad a lot more than I need to see some alert screens brilliantly rendered so I've opted to make Serice my new go-to mode. On my wish list: Fix it so when in Service mode the user doesn't experience the hover-first-see-rendering-after issue by next release ?? 😊 |
This is really great @ChicoThorn ! |
Hi, @snowie2000, want to present my russian translation of macType. Pls, add it to installer |
@Fidelich Thank you! We'll add it to the public release. |
@ChicoThorn The reason that Registry mode stopped working is simply that it doesn't work for all UWP apps from the beginning. You may wonder that it works for almost all the UWP apps like paint, calculator. That's because normal UWP apps are created from a process called However, as I mentioned before, notepad is a win32 converted UWP. Those apps have a very special launch mode and I'm still very confused about how they are created. MacType's parent-children hooking mechanism doesn't work for it and nor does the registry mode. To see the speciality of win32 converted UWP apps, here is an experiment you may like to try:
Have fun. |
@Fidelich you are amazing! Thank you so much 😊 😊 I'm adding it right now. As @snowie2000 says, this will be in the next release 😊 |
@snowie2000 I think Win32 converted apps would be virtualised wouldn't they? Some initial evidence this may be the case https://social.msdn.microsoft.com/Forums/sqlserver/en-US/4f2bf36a-835a-443e-b4fb-97e97a98d141/uwp-desktop-bridge-virtualization-issues?forum=wpdevelop |
Some further research suggests there are several limitations of converted UWP apps, like they cannot be forced to run as Administrator. I haven't time to look into it in detail right now, but hopefully that helps? |
@snowie2000 list of APIs supported only in packaged UWP apps https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api |
Thanks @snowie2000 ! — I'll give that experiment a try... should be interesting! 😊 |
Hi @snowie2000 and @sammilucia ! 😊 In my never-ending quest to find the perfect settings that work in nearly any point size and in either Dark, Light or Mixed Mode I do believe I may be getting very close! Check out my latest screenshots and .ini file. ChicoThorn.ini is now at version 1.5! WooHoo! 😁 First samples of my new settings at 113% scaling: And here's the same .ini settings applied at 100% scaling: The rendering settings from v.15 of the ChicoThorn.ini file The new ChicoThorn - 113% - v.15.ini And finally a .zip file containing all this new stuff... { ChicoThorn MacType Settings· 2019.10.11.zip Let me know what you think! — I notice that the rendering of the Taskbar Jumplist at 100% in Light Mode is a bit thin, but still clear and readable. The grayed subheads on the Settings Page are also a bit light, but again I think they're workable. 😀 Oh! And as for the changes they made in Notepad so it no longer renders... I gave up trying on that one! 😉 Instead I found myself a nice 3rd party Notepad replacement app, which you've probably heard of: TED Notepad. Apparently it's been around for years, and is still being updated from time to time! Gotta love and admire these independent programmers and coders who devote so much of their own time on these great Windows enhancements – I'm looking at you guys! You're the best! 😊 Thanks again for MacType and for your dedication to developing it further! —Thorn |
Hi again! So I was bothered by the fuzziness on the 100% rendering I sent above, especially in Light Mode, so I tweaked the settings a bit more and it's clearer now. That brings ChicoThorn to v.1.5.2 ! Since the fine-tuning changes I made will probably only be able to be seen in the original .png screenshot files, I'll just post the .zip with them in it and forego posting the screenshots here in the thread. 😀😁 The .zip file also contains the updated .ini file. – Thorn Screenshots .zip file: |
I'd say the current release is probably good enough for XP users. Also remember that the v142 builds still support Vista, which is 13 years old at this point, most machines should be able to handle that. Since VS 2017 has both C++17 and XP support, retargetting and hacking together their toolchain would still be an option to compile for XP (which they will need to anyways, since EasyHook bins are also built with v142 now). On the other hand, updating to v142 would allow us to focus on bringing mactype to new platforms, like the ARM64 builds of Windows. |
btw I just fixed the encoding on my branch (so I can edit and play around with the code without destroying the comments) by converting files both from Shift-JIS and GB2312 to UTF-8 and manually reviewing every single line and merging the correct interpretation. It was kind of tedious, but now I can edit code without destroying both kind of comments. Will PR after the current one is accepted since else it'd have some conflicts. |
@snowie2000 @namazso I agree, there are versions that work well on XP and Vista. we can keep those hosted for people who need them, but by your own statement the newer versions don't work well on XP... we need to drop support for future versions so we can move forward. we're a very small team we need to choose our battles, and supporting every OS adds a lot of overhead, bug testing, etc. to do properly. |
Hi everybody! I hope everyone is staying safe and staying well during the age of COVID−19 that we're all in. With all of us having more time on our hands, I thought I'd post my latest .ini file settings, my customized "Microsoft Sans Serif" font which I've used to replace both Tahoma & micross (Microsoft Sans Serif). My customized font is a duplicate of my glyph-customized SegoeUI font with widths and heights of U&lc being tweaked to provide a more eye-pleasing display on surfaces in the UI that default to Tahoma or micross. The result is a more unified experience across the UI. My latest tweaks to the .ini file have proven so pleasing across so many different parts of the UI, that I haven't made any changes to it since February 21, 2020 (which is a long time relative to prior attempts). I have a series of steps I go through after each install of the Windows Insiders Fast Ring updates, and so far MacType continues to provide fantastic results (current Windows Insider Build is 19603.1000 released 2020.04.08). These steps are: (1) Install my customized fonts for SegoeUI and Microsoft Sans Serif in particular. (2) Run MacWiz to reset the Mode used to "Registry" (I still find this mode to be the best overall way to load and use MacType in my experience, and since it continues to work, I will continue to use it). I also reload/reselect my desired .ini profile (although this appears to be unnecessary since it seems to persist build to build). (3) Load my customized font substitutions into the Registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes I exported a registry file with my custom settings a while back, so now after each build I just run that registry file to update Font Substituions more quickly. Thorn Custom Registry Font Subs.zip (4) I double-check my scaling options in Windows Settings — (5) I use WinAero Tweaker to change the default font size of Icons from 9pt to 10pt (which also changes the sizes of all filename text displays in File Explorer). 10pt scaling of the Icons and filenames nearly matches perfectly the 113% scaling produced by the Ease of Access setting, thus providing a very uniform overall look and feel within the UI. Here's a link to WinAero for the download (scroll down past the adds for the download link) — Note: When you install WinAero Tweaker Windows will pop up a security warning that it's 'dangerous.' It is not. I have been using Tweaker for over five years with no problems. Sergey Tkachenko is the sole programmer with a small operation. The software is safe and reliable. https://winaero.com/download.php?view.1796 (6) I make sure my monitor is adjusted and calibrated properly. — This one is important. It makes a HUGE difference in overall font display quality if monitor gamma, brightness, and contrast are improperly set. This took a little trial and error; but using calibration software (and my own eye) to adjust the overall look I was able to come up with very pleasing results. I imagine these settings would differ from monitor to monitor and brand to brand. For me these monitor settings are (input through the onboard settings of the monitor itself): Brightness=85; Contrast=75; Gamma=Medium. I also adjust the Nvidia Control Panel settings to a vibrancy level of 60%. All of these display/monitor settings have a big impact on display ultimately. Finally, here are a few screenshots of my current setup at this time: Edge Canary, Taskbar Jumplist, Action Center sample: Custom MS Sans Serif Font UI samples: File Explorer, Taskbar Jumplist, Settings samples: Thanks for all your hard work on MacType @snowie2000 and @sammilucia ! MacType continues to be the most important add-on to my PC and makes my everyday work so much more pleasurable and tolerable. I'm looking forward to helping out in the future as you develop new versions! Stay well everyone! 😊 |
Thank you, everyone. I'm starting to do a cleanup job now whenever I have time. |
Ok guy, we have a situation. After merging the pr from the great @namazso, I have to rebuild mactype with easyhook32/64 instead of easyhk32/64, which means my previous easyhook needs a rebuild too. After I rebuilt all the files, I discovered that the Chrome (Cent Browser) stopped working. MacType only applies to the mainframe but not the content. I then tried to debug by swopping files and turned out the easyhk64.dll is the key. When I used the old easyhk64 (renamed to easyhook64), chrome worked. Then I compared the two versions of easyhook by asm, and they are basically the same except some differences made by the compiler which are not important at all. I also clear the dllmain proc of easyhook and it still failed to load. Did anyone ever encounter similar problems? Are my old easyhook files sort of whitelisted? |
If there really are only compiler differences between the old easyhk and new easyhook then my immediate thoughts:
|
Total noob here but is it possible that they could have *blacklisted *easyhook
instead of whitelisting easyhk?
Could this be a Cent-only problem or does it affect other Chromium-based
browsers, or Chromium itself?
That said, Cent may very well have whitelisted easyhk to enable MacType to
work... I would if I wanted to make my browser more visually appealing.
…On Mon, Apr 13, 2020 at 7:47 PM Samantha Glocker ***@***.***> wrote:
When I used the old easyhk64 (renamed to easyhook64), chrome worked.
If there really are only compiler differences between the old easyhk and
new easyhook then my immediate thoughts:
1. Can't we just use the old easyhk and not worry about it?
2. Why would Chrome/Chromium whitelist easyhk? A quick google of
"chromium and easyhk" turned up no source code debates (I'd expect some
discussions)... In which case the only logical answers are a) you missed
something in the ASM differences, or b) Cent have indeed whitelisted easyhk
in an effort to continue to support MacType/GDI ... (b) seems like the only
logical answer to me.
3. On this topic (of Cent Browser supporting MacType) we should try to
establish a formal relationship for the sake of both parties.
@snowie2000 <https://github.com/snowie2000> have you a contact there?
If not I can start this process
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#553 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALJKQEZYOC2D6F5LDR2CUHDRMNF3RANCNFSM4HZOP6IQ>
.
|
@sammilucia @namazso Mystery solved! I tried several "mind-blowing" ways to see what has gone wrong with my easyhook, the here is the truth: The easyhook is blacklisted. @kcohar is actually right😆 Yes, it's not my previous easyhook that got whitelisted, it's the original easyhook that got blocked by all chrome variations. More specifically the dll whose original name is "easyhook64.dll" will be blocked no matter what it is. My previous easyhook was built with the name "easyhk64.dll". Although its filename was later changed to easyhook64.dll due to our recent code refactor, its original filename was baked into the executable and didn't get modified along. My new easyhook, on the other hand, is built directly with the name "easyhook64.dll" and thus can't pass the barrier. Proof: Change target name to anything other than easyhook64 and build and rename, the dll worked normally. Change target name back to easyhook64 and rebuild, chrome failed to work with it. Yeah, this is the fundamental difference I have discovered so far. Based on the conclusion above, I think we should stay with my old "easyhk" solution. |
I think it is not blocked rather accidentally (them not knowing of it), and it could very well be blocked in the future. I'd say figuring out how to build and have it run statically would be an overall better solution (unless you know of something that prevents us from doing this?) |
I meant that your build is only accidentally not blocked, however following the links to this it seems like they explicitly aren't blocking MacType, so it's probably all fine. (regardless, I'll look into the possiblity of static linked easyhook, it would be nicer to do) |
@snowie2000 that's amazing! - that's very lazy blacklisting if just renaming can work around it. Great sleuth work! |
I don't think it's good to embed all libs statically. The bootstrap part and the core part shares the same easyhook library. It greatly improved the performance of MacType for compilers because compilers tend to frequently create and exit new processes and they don't have any GUI. |
As I stated in the previous post, renaming doesn't work. You have to rebuild it from source code. Of course, it has never been a problem for hackers. |
Oh okay, that's reasonable. Although I'd rather have a lazy initialization, since loading a bigger dll costs almost exatly the same (and cheaper than two) as long as it "does nothing" ie. no initialization happens, but I can already see how troublesome that would be if we wanted to not load things like GDI32 into non-gui processes |
I have stripped the bootstrap part to make it entirely depend on Plus, the MacType core does a lot of initializations upon dll attaching (although lots of initializations have already been delayed or moved during its development), it would be very difficult to extract all those functions and invoke them at the right time. |
As of CentBrowser 4.2 (Chrome 81) the easyhook* are now completedly blocked no matter which filename you built it with. |
What about regular Chrome (Canary) or Chromium?
…On Thu, Apr 23, 2020 at 7:29 AM snowie2000 ***@***.***> wrote:
As of CentBrowser 4.2 (Chrome 81) the easyhook* are now completedly
blocked no matter which filename you built it with.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#553 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALJKQEZBYEWHIVOLIZSASS3RN7G2XANCNFSM4HZOP6IQ>
.
|
I haven’t tested it yet. Cent is my daily driver. |
Hi @ChicoThorn
I've installed your updated fonts etc and indeed a bunch of things look much nicer, but alas your modified Segoe fonts do not seem to contain a large part of the Central European character set, so I now have random symbols appearing instead of the character such as čš in the text. I would like to go back to the orignal Windows-supplied fonts. How can I do that? |
Hi @wigster, Sorry about that, I forgot that many users would want to use the the Central European character set (which is where I embedded my custom glyphs). I'll need to create a version of my modified Segoe font that doesn't contain my custom glyphs in order for that to work properly. But in the meantime, it's fairly simple to return to the Microsoft supplied fonts and still enjoy MacType's amazing rendering. (1) Reinstall the attached Microsoft default versions of the default Microsoft fonts for SegoeUI and MS Sans Serif (micross). Unzip them, then install these fonts into your system (both for single user and for all users) Default Segoe & micross fonts.zip (2) Unzip the attached "Default Registry Font Subs.zip" Default Registry Font Subs.zip — Open Regedit (Registry Editor) to the following address: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes — In the left navigation pane you will see the "FontSubstitutes" Key highlighted. Right-click it, and select "Delete" — Now, load the "Default Registry Font Subs" that you unzipped by clicking on the .reg file. Follow the prompts to add this to your registry. After you load it, you will now find the Key "FontSubstitutes" is back, but the list is parred down to the original default values provided by Microsoft. (3) Unzip the "ChicoThorn - v.1.5.1.2.3 (this is my latest and best ini settings to date) - MS Fonts" zip file and copy it to your MacType ini folder (located in Programs > MacType > ini) ChicoThorn - v1.5.1.2.3 - MS Fonts.zip (4) Run MacWiz. Select "Registry" mode. Click Next, then on the select profile window select the new ChicoThorn ini file you just copied. — Restart your computer. You should now have Arial, Tahoma, and MS Sans Serif all displaying as they normally would in a default Microsoft setup. Of course, you can always modify your font substitution lists in both the registry and the MacType ini file. I've found it's best if these two lists match up. Hope this helps! Give it a shot and let me know how it goes. 🙂 |
As you know Microsoft has indeed moved many of the Sys32 apps to the Store now... so I've revisited my Mode setting in MacType and have switched over to MacTray Standalone Mode. It works great even on those new converted 'old' apps. I'm still annoyed with the need to hover sometimes first for the rendering to kick in, but on the other hand it's a lot better than not having it render at all as is the case in Registry Mode on those particular apps. Thanks again @snowie2000 and @sammilucia for the insight you provided on this in 2019... it just took me awhile to come to the party! 😊 |
@snowie2000 I'm not sure if you're the one making the wikis, but due to Supermium's capability to load in GDI Legacy and DirectDraw for compatibility reasons, it is actually possible to load it and make the websites have MacType to work! |
@SoftwareType yes, I can add it into the wiki. |
Firefox font changing does work at default, but when it doesn't support it anymore, it might be possible that https://github.com/Eclipse-Community/r3dfox/tags might be the next one to support it, but I highly doubt that it would be the case, since they didn't do much stuff with Fonts for a while |
Possibly everything that runs under Windows XP and Vista compatibility, has GDI Legacy on it. I know that this might be a bit of a harsh task (and issues might "blow up"), but I thought if you could use methods of symbols to make it have some more advanced features or better customization (Symbols method outside the Services one) |
Also just a question; how do I know if DirectDraw works to render? It feels like it sometimes fail in some places |
That's due to the complexity of the DirectX series APIs. There are tons of ways to do the same thing in DX and MS is adding new ways literally every new version... so inevitably, there will always be something missing... |
The MacType rendering engine is a long-term, mature project that has come a long way since it first began in 2012.
There is still a lot of work to do, however, especially in making MacType more accessible to the average user, and improving the apps surrounding MacType (for example, rewriting MacType Tuner and MacType Wizard to make them more modern and maintainable).
If you're an developer, translator, or tester, and you are interested – or know someone who might be interested – simply reply here, or message us directly at @snowie2000 or @sammilucia and let us know. We'd love to hear from you 😊.
The text was updated successfully, but these errors were encountered: