Thank you for your post.
I do not have any fonts that were purchased/licensed, so I'm unable to test this. Therefore, I have sent your post and screen shot to our Testing and Development departments for review. When I receive any feedback, I will let you know.
Hopefully they will respond quickly since this font (bmo5.ttf) is used for the numbers in our invoice system within Filemaker, meaning we have to create each invoice by using Command P at the moment which is no fun for the collegue who is responsible for it.... ;-)
If all else fails, I believe that the MyFMButler plug in lets you script the printing process to the point where you could print using a "PDF printer utitlity".
Our Testers would like to get a copy of your file to verify the script and the layout. Please check your Inbox at the top of this page for instructions where to send the file.
The alert is letting you know that FileMaker Pro is unable to embed the font into the PDF for legal reasons (so that it doesn't come as a surprise when you try to view the PDF later). In this case, the proper PDF file should still be produced that uses the font without embedding it... it should be viewable without problems if the restricted font is already installed on the computer used to view the PDF.
For an urgent remedy, the immediate workaround is to switch to a font with more permissive licensing properties; ideally, if you share documents, you will want to stick with fonts that you can guarantee are installed on any machine used to view the document.
There are a number of ways to look at this issue:
- The warning alert should really have appeared in FMPro v12 as it does in FMPro v13
- The warning alert should be deferred until the script has finished running
- The warning alert should be suppressable by the user (either as an option in the script step, or when running a script, or preference, or whatever)
- There should be no warning alert at all, and users must be informed via other means (readme, kb?) that restricted fonts will not be embedded
Do I understand it correctly that the FM13 behaviour issue will not be changed?
If so, why can I create PDF from within MS Office, Adobe InDesign, Quark Xpress etc. with this font? They have to deal with the same legal stuff and solve it by giving a message about it, but still let you create the PDF with fonts embedded.
So, preferably we would like to see a solution with way 3 you mention above: using the script, getting a message and a choice to proceed or not. Would that be possible?
Friendly regards, Boele
You haven't mentioned whether or not you were able to successfully create the PDF with FM13, only that the warning alert popped up. Are you absolutely certain that MS Office, Adobe InDesign, etc. created the PDF with that specific font embedded into it? Because it is perfectly possible to create a PDF that uses a font without embedding it... the PDF can be viewed as long as the font is already installed on the machine used to view the PDF.
There is a distinction between using a font, and embedding a font. Using a font means the font is selected for displaying text in the PDF; the assumption is that the font will be available when viewing the PDF. Embedding a font means that part (or all) of a font is copied into the PDF as well, just in case the font isn't installed on the computer when the PDF is viewed; there are properties in the font itself which can control whether this copying of the font data is permitted. Even if the font disallows such copying, it can still be used in the PDF (it just can't be embedded into it).
I stand corrected indeed as far as the point of embedding the font in PDF goes. See the attached pic of the properties panel of a PDF file. Two lines of numbers, one in the OCRb the other in a OSX system font. The Avenir font is embedded, the OCRb is not.
However, the PDF created (from InDesign) *does* show the numbers on a computer without the OCRb installed, by using the the Adobe Sans or Serif MM font.
FMP13 creates a PDF that is empty. So it is not possible to succesfully create PDF with FMP13 using the script, in contrast with the other mentioned applications like Quark, InDesign etc.
I'm guessing that the intent here is for a PDF to be produced that can be read on any system, even if the restricted font is not installed on the target system.
If it really is urgent that the desired font is used, perhaps an unrestricted version of the font can be obtained from the vendor? It is also technically possible (though illegal) to modify the font to remove the restriction.
The appearance of the warning alert is an annoyance, and FileMaker can consider an enhancement to suppress/remove it.
If FileMaker produces a PDF file that shows blank text even if the restricted font is installed on the system, then that's definitely a bug. Is the text present in the file, but displaying as blank? (This can be seen by trying to "select" the invisible text in the PDF viewer, and copying it to the clipboard to paste into a word processor, etc.) Is the text completely missing? (i.e. nothing, not even something invisible, is there to select)
FileMaker can/will try to substitute fonts if the desired font does not have the glyphs required to display the text. This usually happens with Asian text (Chinese/Japanese/Korean, etc. characters) when the desired font does not itself have a glyph that represents the desired character, but that sort of thing does not apply here. FileMaker is not likely to support using Multiple Master fonts with the same degree of fluency that Adobe products will use them to synthesize replacement fonts.
Well.. Let's keep this simple:
- pdf's created (with that font) in other app's are done well
- the font was bought, with licence (btw: Is there an update available?)
- a pdf is the way to distribute documents without having the recipient to have fonts installed, without licence conflicts
-> when FM can't produce that document (with one specific font): Either a problem with that font (fontfiles _can_ contain wrong 'code') - or with the app thst creates the pdf (FileMaker)
-> principle of error tracking: When a problem occurs under one single condition, others will appear - sooner than later (-:
Every FileMaker client comes with a bunch of fonts (64Meg's.., I never got why, at least that size), can be that there is a conflict
We've had font problems with FileMaker all over the years - so chances are good that there is a conflict somehow somewhere
Yes, PDF created with other apps are good (InDesign, Quark Xpress, MS Word)
The font was bought with license, it is the latest version
I mistakenly said the PDF created is empt: the PDF created contains a wrong representation of the original text, see attached picture:
The upper field (Veld) is the FM database text with the right representation (1234567890abcdefghiABCDEFGHI)
The field (Veld) under that one shows the result in the created PDF (PQRSTUVWXO etc.)
The box underneath that is the properties -> fonts information window that Adobe Acrobat shows.
Notice that it *looks* like the BmOCRB is used, but it clearly has not or wrongly.
The result PDF was created after clicking away the warning from Filemaker that it "could not embed the font blabla"
Again, the result in any other app gives the right result, and also printing to PDF from within FM13 gives the right result. It is just using the script "Save records as PDF" that gives the error and the wrong result.
Is the content of 'veld' identical in FM and in that pdf? Because it's a different string... (puzzles me)
OCR-fonts: We got them also.. and sometimes, it's problematic when those fonts are in two lib's (i.e. system ans user)
The content in the pdf is the *result* of creating the pdf with the "save records as pdf-script" from the FM13 file. So yes the string should be the same but no it is not. :-)
The OCR-font is only in the system font folder and nowhere else. I also tried it with the font in the user library font folder since I know that makes a difference sometimes, but that didn't solve the problem either. It is really a FM13 thing.