Microsoft Font Validator runs native on Mac OS X!

(I think this deserves its own post thread!)

I wrote before Christmas that I was making the font validator run standalone as mac os X command line binary, no need to install mono separately. So it comes.

There is a FontVal-MacOSX-*.tgz under
(current 2016-01-06):

http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/

 If you have an up to date freetype (from macport/homebrew, Xquartz[?], or built your own), you just run it plain. If you have a vanilla mac os X box without any of those, you set DYLD_LIBRARY_PATH to where you unpack the "Darwin" subdirectory - there are just 3 files, the binary, and a subdirectory of up to date freetype dylib, and libpng (which freetype depends on), which you don't have to use.

It is mainly tested on Mavericks, so I'd like to hear from people trying on Yosemite and El Capitan.

I am having problems making the GUI run standalone on Mac os X without mono. More details about this later.

Please feel free to click 

http://sourceforge.net/p/hp-pxl-jetready/donate/
«134

Comments

  • Works on MacOS 10.10. It produces nice HTML that works fine in Safari. 
  • That's great! Yay!

    That said, I know it may seem overly basic, but you need to provide truly step by step instructions so that the average Mac user who has never set a path variable in their life will be able to follow it. Probably half the potential audience for this tool doesn't know how to do that.
  • I personally just prepend the command with the variable, I.e. Doing:

    DYLD_LIBRARY_PATH=<someplace>/Darwin <someplace>/FontValidator 

    Instead of 

    <someplace>/FontValidator

    Where "<someplace>" is the unpacked folder somewhere under /Users/Hintak or Desktop .

    There are more persistent ways of doing this ("export ..." per session or editing .bashrc - permanent) but I won't go into details. Just prepending is easy enough.


  • I simply copied everything into /usr/local/bin
  • If you don't mind that, yes, copy the binary into /usr/local/bin (and the two dylib's into /usr/local/lib - the two libs are universal triarch and up to date and should be better and no worse than their equivalent from macport/homebrew ) is good.

  • If any people find the native executable useful, or think it is neat, or like the GUI to work also, please do consider making a donation of say, £50/€50/$50.

    Trying to make the GUI native is suffering from the mac os X version of DLL hell at the moment. Apple ships a hardware-accelerated libJPEG in Core.Graphics ; mono's interpreter/VM depends on Core.Foundation (which includes Core.Graphics), while the GUI layer has its own private vanilla libJPEG . The application gets a bit confused about which copy of libJPEG to load and in what code path if one tries to build and bundle it all together...
  • The html report from the current Mac version can be displayed in safari. Why not just use a webview instead of getting the original XML viewer to work?
  • The html report from the current Mac version can be displayed in safari. Why not just use a webview instead of getting the original XML viewer to work?
    Not sure what you mean by that - the new code uses webview on Linux, although it may not be obvious. There is very little of the original xml report viewer code left, though the new code also uses MSIE on windows. It is just capable of switching, depending on what it finds. Safari's html capability isn't exposed as a shared library, unfortunately.
  • Hin-Tak Leung said:
    The html report from the current Mac version can be displayed in safari. Why not just use a webview instead of getting the original XML viewer to work?
    Not sure what you mean by that - the new code uses webview on Linux, although it may not be obvious. There is very little of the original xml report viewer code left, though the new code also uses MSIE on windows. It is just capable of switching, depending on what it finds. Safari's html capability isn't exposed as a shared library, unfortunately.
    It is. https://developer.apple.com/library/mac/documentation/Cocoa/Reference/WebKit/ObjC_classic/
  • The new xml viewer code already uses webkit - it is just that it uses webkit in the form of shared library (I.e. webkit.so or webkit.dll).
  • Okay, no more messing with command lines or environment variables. New mac os "FontVal-*.dmg" disk image:

    http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/

    You just download, double click to open the disk image, which contains exactly one icon to click. You double-click that, it launches the GUI !

    I feel that I should get some donation on this, so please do make one (
    http://sourceforge.net/p/hp-pxl-jetready/donate/) if you find this neat .
  • And spread the word!!! Should be user-friendly enough?
  • @Mark Simonson on the other thread had kindly tested, and offered three advices:

    - you could option-drag the whole volume to /Applications (there are invisible items in the volume) if you don't want to unpack the disk image all the time.

    - most likely you should go into report options to write report to font location or your choice, since the default of immediate viewing with built-in viewer does not work currently yet.

    - if your box had never had any other fontconfig-based (basically any Unix-GUI) application installed, the first time you run the GUI there is possibly a substantial delay to build the font cache. This should happen only once until you have a major OS upgrade (when your collection of system fonts changes).
  • When I try to run it, it opens Terminal and then 'exit'. :/
  • When I try to run it, it opens Terminal and then 'exit'. :/
    Did you try to copy before running also? Don't. The clickable icon is supported to be run from the mounted disk ( with some invisible content) directly.
  • Ramiro EspinozaRamiro Espinoza Posts: 839
    edited January 2016
    Yes I did, but I also tried to run it from the image and the same has happened.
  • Yes I did, but I also tried to run it from the image and the same has happened.
    Are you on El Capitan by any chance? I read that some of the things I do in the launch script will not work on El Capitan due to tightened security in the loader.

    When you click on the icon it is supposed to open a terminal which says something about "... /FontVal ; exit" . It may take a while before the GUI appear (during the font cache build)- do not close the terminal. When it finishes (or fails) it will says "process completed" or something.


  • 10.10.5 running here. I will try again and report.
  • OK, now it works. Running it from the image is the only way to make it work?
  • OK, now it works. Running it from the image is the only way to make it work?
    Good to know! You can option-drag the whole volume to copy the whole thing elsewhere. That's pressing the option (the funny sign button next to the space bar, "alt" may also work) while you drag with the mouse. If you are comfortable with the command line, "sudo cp -ipr /Volume/FontVal-2016_01_06 /Applications" should do also.
  • Maybe I should make things one level deeper so that it is one folder inside the volume...
  • It starts over here, but after validating it does not show any results but the message ‘XML viewing not fully implemented on non-Windows […]’. AFAIK this is a libgluezilla-related error. Actually this is as far as I came by just using the original FV installer under Wineskin (with manually adding the ‘var’ folder stuff to the C: drive):


  • It starts over here, but after validating it does not show any results but the message ‘XML viewing not fully implemented on non-Windows […]’. 
    If you look in the directory it tells you about you find the html file you can open in a browser :) 
  • It starts over here, but after validating it does not show any results but the message ‘XML viewing not fully implemented on non-Windows […]’. AFAIK this is a libgluezilla-related error. 
    For what it's worth, not only do I see this in this new version, but the Windows version throws the same error in Windows 10, and unless Windows 10 is considered a non-Windows system... <shrugs>

    Micah
  • Sorry to hear there are some remaining install/run issues, but this still seems like a great direction for the Mac installer!
  • It starts over here, but after validating it does not show any results but the message ‘XML viewing not fully implemented on non-Windows […]’. AFAIK this is a libgluezilla-related error. Actually this is as far as I came by just using the original FV installer under Wineskin...

    It isn't a libgluezilla error. That's because you are using wine-mono with wine. If you want to use Font-Validator under wine on Mac os X ( I do that under linux too), you need to use winestricks to remove wine-mono and install donet runtime v2 instead. If you do that, either using the hybrid branch or 2016-01-06 would give you full xml report viewing functionality ,with either wine-gecko or ie 8.

    I don't want to go into details on running it under wine, but I actually keep three wine installs, vanilla wine (I.e. Wine + wine-mono), wine + donet 2 ( i.e. + gecko) and wine + donet 2 + ie 8 for testing.

    Ie 7 and ie 6 does not work correctly under wine; nor wine-mono enough for running the xml viewer.


  • For what it's worth, not only do I see this in this new version, but the Windows version throws the same error in Windows 10, and unless Windows 10 is considered a non-Windows system... <shrugs>

    Micah
    What kind of error do you see with windows 10? Mind you this is the mac os X thread... Are you running wine configured to win 10? Same comment applies - ripe wine-mono out and put donet v2 in with winestricks.

  • Wine-related issues.
    I haven't gotten round to file those bugs at wine's bugzilla - it is on my TODO list. There are, as I said, at least 3/4 of those: wine-mono does not work (vs donet 2), ie 6, ie 7 does not work (vs ie 8), etc.
  • ... AFAIK this is a libgluezilla-related error....
    Oh, if you want to use the wine + dotnet 2 + gecko combo to have the xml viewer working, you need to set WINEPREFIX explicitly to $HOME/.wine , though that's the default. (dotnet v2 + ie 8 would be better if you are not an open-source purist but just want best functionality)

    The wine people had done a terrific job in the last 15+ years, but the MSIE Active X control (used by the xml viewer code) is one part they have not quite conquer.
  • It starts over here, but after validating it does not show any results...

    You can change the location of the reports in the menu Validation>Options to a directory of your choice or the same directory as the fonts you're validating.

    I found it also helps to uncheck the option to display the results immediately after validation, since it can't do that yet anyway. This way you eliminate the inevitable error message you otherwise have to dismiss each time a report is finished.

    The reports can be viewed in any web browser.
Sign In or Register to comment.