Feature Request - Font Preview - Page 2

theducks · 03-02-2020, 05:47 PM

Quote:

Originally Posted by DiapDealer

I haven't found a single embedded font in any epub I have that it will work with yet on Windows 10 x64

But the fact that it's working for others should come as good news to the OP!

same result you are getting.
I wonder if the ones (PC) that worked were Upgrades from W7?

DiapDealer · 03-02-2020, 05:53 PM

Quote:

Originally Posted by theducks

same result you are getting.
I wonder if the ones (PC) that worked were Upgrades from W7?

The virtual machine at home (that it works on) was a fresh install of Windows 10. The laptop at work (that it doesn't work on) came with Windows 10 pre-installed. Both have been updated to the latest Windows 10 version.

Good to know it's not just me, though!

Turtle91 · 03-02-2020, 06:48 PM

FWIW - Open With does not work for my fresh Win-10 64 install. It says it is not a valid font file, but will open directly using fontview.

I thought there was another thread on this topic here that recommended the font display (as fontview does) in the code view window when highlighted/selected in the Book Browser like images do?? Is that functionality something that can be done with a plugin? The other idea would be to have it display in the preview window when highlighted/selected... just throwing out ideas.

BetterRed · 03-02-2020, 06:59 PM

OW works on my Dell Alien Alpha and it was upgraded from Win 7 to Win 10. But Sigil and similar weren't on it at the time of the upgrade. I did the upgrade when I decided I could use it for purposes other than games.

Quote:

Originally Posted by DiapDealer

And yet it works as expected on a virtual Windows 10 machine at home. So something is clearly wrong with the machine at work that it doesn't work on.

Tell them you need a new computer (with Eizo monitors and Titan video adapters)

Added: Or you could try an Inplace Upgrade of Windows, then you won't have to reinstall applications, make sure you uninstall any 3rd party AVs before you do it. The only apps I've lost were Firefox and Chrome, I had backups of their profiles.

BR

DNSB · 03-02-2020, 07:22 PM

Quote:

Originally Posted by theducks

I wonder if the ones (PC) that worked were Upgrades from W7?

It works on all three physical machines (2 Windows 10 installs and one upgraded from Windows 7 to Windows 8.1 and then to 10). It also works on my 2 Windows 10 VMs (one release, one insider preview).

DiapDealer · 03-02-2020, 07:35 PM

I'm betting the ones it doesn't work on have a username with a space in it. It doesn't seem to affect other programs configured for "Open With" for other filetypes, so I'm guessing it's something to do with how fontview.exe itself parses a path with a space in it when it's provided as an argument.

I'm not at my computer to test, but it's the only thing that makes sense to me. My work machine's username has a space in it (not my doing). Moving Sigil's scratch directory to a location with no spaces in the path (and/or using an alternate font tool with the default space-infested scratch directory) should quickly prove my theory.

DNSB · 03-02-2020, 07:40 PM

Quote:

Originally Posted by DiapDealer

I'm betting the ones it doesn't work on have a username with a space in it. It doesn't seem to affect other programs configured for "Open With" for other filetypes, so I'm guessing it's something to do with how fontview.exe itself parses a path with a space in it when it's provided as an argument.

I'm not at my computer to test, but it's the only thing that makes sense to me. My work machine's username has a space in it (not my doing). Moving Sigil's scratch directory to a location with no spaces in the path (and/or using an alternate font tool with the default space-infested scratch directory) should quickly prove my theory.

I just spun up a new VM from template and created the user with a space in the name. Installed Sigil, attempted to open a font file and errored out. Give the man a virtual cigar! I think he's got the answer. Hmm... wrapping the open with string in "s?

DiapDealer · 03-02-2020, 07:57 PM

Verified. Fontview.exe doesn't like a path argument enclosed in quotes whether the path has a space in it or not. I don't think I've ever run into a windows program that wouldn't accept a path argument enclosed in quotes before (provided a path to a file to open can be passed in as an argument in the first place). Weird. And the Windows Open With code uses methods that automatically build the parameter string and add quotes wherever deemed necessary. Works with just about every other program I've ever tried it with except fontview.exe ... spaces or no spaces. Have I said "weird" yet?

un_pogaz · 03-03-2020, 03:10 AM

Quote:

Originally Posted by DiapDealer

Verified. Fontview.exe doesn't like a path argument enclosed in quotes whether the path has a space in it or not. I don't think I've ever run into a windows program that wouldn't accept a path argument enclosed in quotes before (provided a path to a file to open can be passed in as an argument in the first place). Weird. And the Windows Open With code uses methods that automatically build the parameter string and add quotes wherever deemed necessary. Works with just about every other program I've ever tried it with except fontview.exe ... spaces or no spaces. Have I said "weird" yet?

What??

testing
Yep
I confirm. fontview.exe does't accept quotation marks as command line arguments.
Dammit, even the basic Drag and Drop (if there is a space in the name) doesn't work!
(probably a legacy of very old Windows version)

I don't know if you could do anything to make sure fontview.exe works (although it's really useful).
But if not... too bad (and damned Microsoft)

KevinH · 03-03-2020, 07:03 AM

Could you create a shell or bat file to copy the font file to a temp location that had no spaces in its path, then open fontview, and of course clean up by removing the font file upon exit. Then use open with to launch that bat file.

Would that work?

DiapDealer · 03-03-2020, 07:47 AM

It's possible just creating a batch file to launch fontview and passing it the path as a parameter might work without needing to copy the fontfile at all. Sigil's Open With works entirely different on Windows for launching batch files than it does for launching exe's.

The batch file route might offer the use of command-line switches to handle parameters for fontview.exe properly.

I still may knockup a plugin for this. Windows batch file/powershell chicanery is above the paygrade of the average Windows user.

Turtle91 · 03-03-2020, 08:51 AM

I checked my setup as well - there are no spaces in the path to my fonts (C:\Users\ddgra\Documents\eBooks\Fonts) but the temporary files folder had spaces (C:\Users\ddgra\Documents\eBooks\Sigil Temp Docs). When I changed the temp folder to not have spaces the open with works fine.

'Twould be convenient, though, to double-click a font file and have it open automatically in the main window, like images do. But certainly not critical.

KevinH · 03-03-2020, 09:06 AM

There is already information about the font provided by the tooltips by hovering over the font file in BookBrowser. If you really only must see the font in action simply select some text and apply the css and look at the font as it appears in Preview.

Feature bloat is really not a good thing when there already is system software that does the same thing but better. The problem in not with Sigil here but with the fontview software on Windows not working as it should.

DiapDealer · 03-03-2020, 10:10 AM

I was wrong. Looking at my Windows Open With code, using a batch file probably won't help. With batch files, it explictly adds quotations around the filepath arguments.

There's just no way to handle this well without special-casing fontview.exe (something I'm not willing to do). The code to handle arguments for exes is left entirely up to Qt/Windows. One or the other (or both) decides whether quotes around arguments are needed or not.

BetterRed · 03-03-2020, 11:33 AM

Surely there's an alternative program to fontview.exe that people with spaces in their Windows account name can use to view fonts via Sigil's Open With.

Quote:

Originally Posted by KevinH

Feature bloat is really not a good thing when there already is system software that does the same thing but better.

Quote:

Originally Posted by BetterRed

For me interoperability has always trumped all-in-one. It's a losing battle though, today every user wants every app, to have a button for every feature they ever saw in every other app they ever used.

BR

03-02-2020, 07:35 PM	#21
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'm betting the ones it doesn't work on have a username with a space in it. It doesn't seem to affect other programs configured for "Open With" for other filetypes, so I'm guessing it's something to do with how fontview.exe itself parses a path with a space in it when it's provided as an argument. I'm not at my computer to test, but it's the only thing that makes sense to me. My work machine's username has a space in it (not my doing). Moving Sigil's scratch directory to a location with no spaces in the path (and/or using an alternate font tool with the default space-infested scratch directory) should quickly prove my theory. Last edited by DiapDealer; 03-02-2020 at 07:37 PM.

03-02-2020, 07:57 PM	#23
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Verified. Fontview.exe doesn't like a path argument enclosed in quotes whether the path has a space in it or not. I don't think I've ever run into a windows program that wouldn't accept a path argument enclosed in quotes before (provided a path to a file to open can be passed in as an argument in the first place). Weird. And the Windows Open With code uses methods that automatically build the parameter string and add quotes wherever deemed necessary. Works with just about every other program I've ever tried it with except fontview.exe ... spaces or no spaces. Have I said "weird" yet? Last edited by DiapDealer; 03-02-2020 at 08:03 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
feature request: ctrl+A in in the "file preview"	valida	Editor	5	09-13-2017 07:18 AM
[Feature Request] - Ability to increase dictionary font size	Marcy	Marvin	2	03-29-2014 04:09 AM
Feature Request - Change Size of Library Title Font	Noventer	Marvin	1	03-13-2014 07:27 PM
Small feature request for Preview window	GrannyGrump	Sigil	0	03-12-2013 02:57 AM
Feature Request: clickable Cover Browser & font size	Joanna	Calibre	2	04-23-2012 11:41 AM

03-02-2020, 06:48 PM	#18
Turtle91 A Hairy Wizard Posts: 3,355 Karma: 20171571 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	FWIW - Open With does not work for my fresh Win-10 64 install. It says it is not a valid font file, but will open directly using fontview. I thought there was another thread on this topic here that recommended the font display (as fontview does) in the code view window when highlighted/selected in the Book Browser like images do?? Is that functionality something that can be done with a plugin? The other idea would be to have it display in the preview window when highlighted/selected... just throwing out ideas.

03-03-2020, 07:03 AM	#25
KevinH Sigil Developer Posts: 8,766 Karma: 6000000 Join Date: Nov 2009 Device: many	Could you create a shell or bat file to copy the font file to a temp location that had no spaces in its path, then open fontview, and of course clean up by removing the font file upon exit. Then use open with to launch that bat file. Would that work?

03-03-2020, 07:47 AM	#26
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	It's possible just creating a batch file to launch fontview and passing it the path as a parameter might work without needing to copy the fontfile at all. Sigil's Open With works entirely different on Windows for launching batch files than it does for launching exe's. The batch file route might offer the use of command-line switches to handle parameters for fontview.exe properly. I still may knockup a plugin for this. Windows batch file/powershell chicanery is above the paygrade of the average Windows user.

03-03-2020, 08:51 AM	#27
Turtle91 A Hairy Wizard Posts: 3,355 Karma: 20171571 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	I checked my setup as well - there are no spaces in the path to my fonts (C:\Users\ddgra\Documents\eBooks\Fonts) but the temporary files folder had spaces (C:\Users\ddgra\Documents\eBooks\Sigil Temp Docs). When I changed the temp folder to not have spaces the open with works fine. 'Twould be convenient, though, to double-click a font file and have it open automatically in the main window, like images do. But certainly not critical.

03-03-2020, 09:06 AM	#28
KevinH Sigil Developer Posts: 8,766 Karma: 6000000 Join Date: Nov 2009 Device: many	There is already information about the font provided by the tooltips by hovering over the font file in BookBrowser. If you really only must see the font in action simply select some text and apply the css and look at the font as it appears in Preview. Feature bloat is really not a good thing when there already is system software that does the same thing but better. The problem in not with Sigil here but with the fontview software on Windows not working as it should.

03-03-2020, 10:10 AM	#29
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I was wrong. Looking at my Windows Open With code, using a batch file probably won't help. With batch files, it explictly adds quotations around the filepath arguments. There's just no way to handle this well without special-casing fontview.exe (something I'm not willing to do). The code to handle arguments for exes is left entirely up to Qt/Windows. One or the other (or both) decides whether quotes around arguments are needed or not.

Advert

Advert