Unibook

ClintGoss

I'm working with Unibook to print code charts and ... hoping someone might have similar experience with the (teeth-gnashing) issue I'm facing:

Glyphs in my font come out blank when the code chart is printed to PDF.

The glyphs appear AOK on screen. They print fine to my HP printer. Blank squares with PDF.

I'm printing just a single block (working with Cherokee currently). My font is large (6MB ttf), so I tried subsetting it with pyftsubset to just the Cherokee block (21K ttf), but the results are the same.

Unibook 6.1.1 Build 260.4, Win10x64, 

Might there be a Unibook discussion group anywhere??

Much appreciation for any advice, pointers, as I'm at wits end ... (Hmmm ... good font name "Wits End" ...)

Alan Bernard Hughes

It looks as if Unibook is checking within the font to see if there is permission to embed the font in a PDF. If I am thinking correctly, and this is a font that you have made, then perhaps your font-making program sets the most restrictive rules by default.

Go to the legal section of your font-making program and look for "Embedding Licensing Rights" or equivalent; select "installable" or "editable"; save the font; re-install the font; use the new version of the font in Unibook.

I hope this makes sense.

ClintGoss

Thanks Alan ... but No, it's not embedding rights. I have those ducks all lined up  (I'm setting the bits directly from a perl script in my pipeline)

I am currently playing with alternate PDF "printer" drivers - it could be a problem particular to Adobe's print-to-PDF facility, but I'm working through how to replace / upgrade that component ... 

Nick Curtis

You could also save as an EPS file, type converted to curves, and distill a PDF from that.

Peter Constable

On the Unibook page, there's a contact link for Unibook issues. 

John Savard

One question I have for you: if you use a word processing program, or even WordPad, and use Character Map to put Cherokee characters in your document, which you then cause to be in your typeface, do documents of that sort print properly in PDF? That would help isolate the problem, to make sure it is a Unibook issue.

ClintGoss

Good idea for a test. Yes, I can print to PDF from other apps through the same drives any characters, including CJK and PUA code points.

ClintGoss

I have been working for a number of (long) days with Unibook, and have found a number of issues and "quirks" that may be helpful to others who wish to produce code charts through Unibook. There seems to be no on-line community surrounding Unibook (although they do provide mailto:unibook@unicode.org for suggesting update), so I'm posting these observations here, in the hopes that folks who might need this info will find it ...

Caveats: I have not researched these issues deeply. I have been working towards producing code charts for my project, encountered these speed-bumps, dealt with them with work-arounds and hacks, and moved forward with my project. Many of my thoughts on the bounds or causes of a particular issue are blind guesses which I have not tested. Also, I am focused on producing PDF code charts, not using Unibook as an interactive character browser. Also, I am currently working with Unicode ver 12.1.0.

Basics: Unibook 6.1.1 (Build 260.4 - circa 2012) on Win10x64. Install package available at https://unicode.org/unibook/. Documentation (of various forms) at https://unicode.org/unibook/help/unibook.htm and https://scripts.sil.org/UnibookWalthru

Unibook takes a (large) collection of configuration files and produces a PDF document containing optional Title Pages followed by interleaved Grid Charts and NamesList Tables.

Specials Fonts: A set of 3 "Specials" fonts are provided with the distribution that need to be installed. They provide glyphs for the "Dashed-Box" characters used as replacements for control characters, formatting marks, and other code points that would otherwise be problematic to display in the Grid Charts.

Although Unibook 6.1.1 was tested against Unicode 6.1, it was designed to accomodate the configuration files of later versions of Unicode. It largely does this, but not without some massaging. Out of the box, the Unicode v12 NamesList.txt cannot be parsed and must be hacked to get through Unibook. Also, the Specials fonts do not provide all the dashed-box character needed for versions of Unicode beyond v6.

Printer Drivers: Printing to various versions of Adobe PDF printer drivers does not work. No idea why, but the Grid Box characters are absent. However, the "Microsoft Print to PDF" driver does work. The internal format of the PDF produced by those two drivers is different, which caused the later components of my pipeline (which set PDF meta-data using Perl scripts) to fail. I got around this by opening the PDFs generated by the Microsoft Print to PDF driver in Adobe Acrobat and saving them.

Title Pages: Unibook refused to print the title pages. I found that there is a Mode setting in the .fmt configuration file that is a bitmap which controls various Unibook behavoir. By playing with the bits, I found that Bit 2 controls File Statistics, Bit 8 controls the title page, and Bit 14 is described below.

High PUA: Blocks in the SPUA-A and SPUA-B zones would not print without the last two characters of the range being included. No idea why. For example F0000-FFFFF works, but F0000-FFFEF causes Unibook to stop showing output. There is a recommendation on the help page to set [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack] SURROGATE=(REG_DWORD)0x00000002, but this had no effect in my situation. However, after hours of messing around, I found that setting Bit 14 of the Mode value cured this problem.

I would suggest that, if you encounter some quixotic, bug-like issue, try setting Mode to FFFFFFFF and then 00000000. Things will get pretty messed up, but if you can determine whether your bug-like issue went away, you may be able to isolate the bit that turns cures the issue.

PDF Truncation: At one point in my development, output to Microsoft Print to PDF started becoming truncated and corrupted, with no error message from Unibook. I tracked down the issue (more hours of messing around) to a cross reference to a code point in the SMP (1F674) that has no font mapped to that code point. There is no problem if the .CFL file has a font provided for the range which happens not to have a mapped code point for that cross-reference point (Unibook shows .notdef). The problem happens if there is no font mapped to that code point.

E200 Mapping: Unibooks uses areas of the PUA for various glyphs needed to generate the code pages. There are largely configurable in the application and/or the configuration files, with the exception of a block starting at E200. I found by experimentation that Unibook uses the range E200-E27F. These characters are used for decompositions.

What happens if you're generating a code chart for that part of the PUA? Then simply do not map a decomposition font to that range in the .cfl file. However, this effectively disables decompositions. So, there is not way (AFAIK) in Unibook to create a code chart for a PUA block in the E200-E27F range that has decompositions.

OpenType Layout directives: I encountered problems with displaying Grid Glyphs from a font (Sylabitsa Sans) that I think was using default OpenType Layout directives for its "normal" display of characters. I did not pursue this very much, but I think that Unibook is not generally OpenType aware.

I hope this helps!

Peter Constable

One thing to be aware of: the primary purpose for which the UniBook app was created was production of The Unicode Standard and the ISO/IEC 10646 standard. Along the way, it was thought that it could be useful to provide a version of the app for others to used. But there was never a commitment to keep a public version up to date. In recent years, resourcing constraints have probably curtailed significantly how much has been done to update the public version.

Some of the documentation and guidance reflects this. E.g., the download page makes reference to Windows XP and Windows Vista. That gives an idea of how long it's been since documentation was updated. That HKLM\...\LanguagePack registry entry is incredibly old and has been obsolete since (IIRC) Windows Vista. (IIRC, it was at one time a way to enable use of the Uniscribe component in GDI / User text display, but since Vista Uniscribe was always enabled in every system.)

I'd still encourage you to provide feedback: more feedback just possibly might drive a bit more prioritization toward maintenance of the public version. (But not guaranteed.) In the meantime, I applaud your effort at figuring out how to make it work, and sharing your insights,

Simon Cozens

Depending on what you're using Unibook for, you may have more success with fontproof, which uses my SILE typesetter to produce font proofs, including Unicode Standard-style character code charts. Here's an example:

\begin[class=fontproof]{document}
\setTestFont[family="Gentium Plus"]
\font[size=30pt,weight=700]{Range test}\par
\unicharchart[type=range,start=0100,end=01F7,columns="12",rows="16"]
\end{document}

ClintGoss

Simon Cozens said: Depending on what you're using Unibook for, you may have more success with fontproof, ...

 How interesting! Was not aware of this ... 

It fontproof known to work on Wintel (Win10x64 specifically?) I could not immediately tell from the fontproof info ...

In any case, I am quite far down the rabbit hole at this point ... a 200+ page user guide and a flock of Specimen Book documents for my array of fonts. In any case, my target audience is academic users authoring with Microsoft Word, so I feel I have to use MS Word to author as much documentation as possible. Unibook is the exception, since it is exactly what is needed in terms of familiarity (so many folks use the Unicode code charts), and the ease of decompositions and annotations ...