Font support in Adobe form
Font support in Adobe form
版权声明：署名，允许他人基于本文进行创作，且必须基于与原先许可协议相同的许可协议分发本文 （Creative Commons）
Firstly, we support any OpenType, TrueType and Type1 fonts. So we can support anything the user chooses to have. But I don’t think that’s the question you want answered.
You probably think you want to know what fonts we actually supply with the ADS, Designer and Reader. The attached spreadsheet details the fonts that we supply and gives some characteristics of them. Note that we also support “Helvetica” and “Times” but we don’t ship them. They usually map to Arial so you can consider them as being present. They are Latin1 only.
Also note that the fonts we supply are based on language set not on style. So for example AdobeArabic is Arabic and Latin1 but the Latin1 characters are very different from the Helvetica Latin1. The ones in AdobeArabic are smaller and look better when mixed with Arabic characters. So allowing the A1S users to choose a font is not a matter of style - it’s a matter of what language set they will be using in the form. There is no single font that covers all the character sets. So choosing the fonts doesn’t seem such a useful thing for their users to do.
But you’re not done yet. You also need to think about where the results you produce are going. The final “device” needs to have the fonts as well. That means either the printer (PCL & PS) or the end user workstation (PDF) needs to have the fonts. If you stick with the Adobe fonts, they are available to all customers. We don’t actually ship them all with Reader but Reader can update itself and download them when it first needs them. The installer can also include them if you request it. But any other fonts, not supplied by Adobe need to be either on the desktop or embedded in the PDF. If you embed them in the PDF, they need to be marked as embeddable. That’s a licensing issue you need to think about when you buy the fonts. PDF also has the ability to fake out a font. By knowing the general type of font (size, bold, serif, slope) we can approximate the font if it’s not available on the desktop.
But for printers the problem is both similar and different. It’s similar in that you need the font but different in that we can’t fake it out. If the font is not available on the printer, we have to download the font. That’s another permission bit that’s set in the font when you buy it. But if the font is not available on the device or if we are not allowed to download it, we will go and choose another font. Cascading fonts is the way you can control the mapping of what font gets chosen when the font is not available on the device.
Of course, for printers, we need to have some way of knowing what fonts are available. The XDC editor allow us to create an XDC that contains the font definitions that exactly correspond to what’s on a printer. We need to have a soft copy of the font to import into the XDC Editor so we can add the font to the device. And lastly, you need to remember we only support certain character encodings for printers. We don’t support Unicode. We do Support the standard CJK encodings and Latin2. See the ECO on printer resident font encodings in the eRoom.
Now lastly, remember that changing the fonts in a template in A1S is going to take a little special work as well. There is additional information that Designer inserts into the template that is not strictly part of XFA. I believe it is saved as a PI and is call psmap information. It basically tells the ADS some general characteristics of the font in case it is not available. It defines the general style of typeface, and also information such as serif, weight, slope etc. If ADS want to plug fonts into templates they should maintain the psmap info as well.