Help! Federal W4 form always requires Japanese font pack

[wpinegar]

Hi! I've been tasked with automating the new hire process and the client would like to include the Federal W4 form in with a collection of other forms required for their internal new hire paperwork. So I download the form from http://www.irs.gov/pub/irs-pdf/fw4.pdf, opened it in LiveCycle Designer 7.1 (on Windows XP), then saved the resulting LiveCycle form as a PDF. Now any time I try to open the form in Acrobat Reader 7.0.8 it goes to the web and requires that the Japanese font pack be installed. If I don't install it the form behaves very strangely, such as form field text disappearing anytime to tab off of them.



Now if I reopen the the newly created W4 LiveCycle PDF in LiveCycle Designer and save it as an XPD file I can see that the font "Kozuka Mincho Pro-VI R" has been inserted into the document. I have confirmed that this font is not present in the original Federal W4 from. My question is why is this font being added and how can I get rid of it? This has to be a bug.



Can anyone else reproduce this problem?

[_Aandi_Inston_]

Any reason why you aren't working with Acrobat forms?



Aandi Inston

[wpinegar]

I have compaired the two methods for forms development supported by Adobe (Acroforms and LiveCycle forms) and found forms development in LiveCycle to be much more intuitive. LiveCycle does have it's downsides but overall the product develops very rich forms (than what can be done in Acroforms). The only issue I've had so far with LiveCycle is with this Federal W4 form, everything else has worked perfectly fine.



Anadi, were you able to reproduce this bug?

[Former Community Member]

Upon importing that Acrobat form into Designer there are many fonts used in the PDF that Designer cannot find off the bat. It asks you to choose fonts to substitute for them. You can also click a button and tell it to use default fonts. If you do this it will use Myriad Pro in most cases (which is the default font in Designer). There is a character in the form that is not a symbol in Myriad Pro, it looks like a black filled in diamond. It is however found in Kozuka Mincho Pro-VI R. So that is used when generating the PDF and that is why you are told that the Japanese languange pack is needed. If you don't want that to happen you need to set the fonts in the form such that it uses a font for that character that has that symbol and is not a Japanese font.



Also there is some JavaScript on the form that likely won't work properly on a Designer form, you'll need to change these scripts so they will work.



Chris

Adobe Enterprise Developer Support

[wpinegar]

Chris,



Thank you for your reply. When I opened the W4 PDF file I decided to map all substitute fonts to the standard Ariel font, I did not allow LiveCycle to use the default font. I even went so far as to tell LiveCycle to "Permantently Replace Unavailable Fonts" when I saved my new LiveCycle PDF but still the "Kozuka Mincho Pro-VI R" is required. When I reopen the new PDF in LiveCycle I don't event see "Kozuka Mincho Pro-VI R" in the lists of fonts to substitute.



There is definately a bug here. I cann't get rid of the requirement for this Japanese font. I don't even have the font pack installed on the LiveCycle workstation.



Were you able to work around this issue in LiveCycle? If so can you tell me exactly what steps you performed to get rid of this font from the LiveCycle PDF? Simply download the Federal W4 form from the web site and try to produce a LiveCycle form from the PDF. I haven't been able to create a LiveCycle form that doesn't require Japanese fonts.

[Former Community Member]

Yes, I able to import the form and get it to work. After importing I deleted all the bullets, then I created new ones using a WingDings bullet character.



Chris

Adobe Enterprise Developer Support

[wpinegar]

Chris,



You're good. Yes, this does work to fix the problem. Thank you. I see now that the warning display shows that it was substituting the unknown character in the W4 form to the Japanese font. Out of all of the fonts to use do you know why a Japanese font was selected by LiveCycle?



I appreciate the help! By the way, the new corporate new hire packet is 24 pages in total size. I have noticed LiveCycle is getting pretty slow during cut/copy/paste and moving objects around on the forms. It works well when the # of pages is small but with 24 pages LiveCycle is under a bit of a strain.



Are there any improvements in performance coming to address large document issues?

[Former Community Member]

Likely it chose the Japanese font because it was the first one it found on the system that contained a glyph that corresponded with the unicode character number that is used in the form. I'm far from a font expert and frankly I often have trouble wrapping my head around more complicated font issues so that is more of a guess than a certain answer. I think if you were able to find the exact font they used when creating the form and installed it on your system it would all work without having to replace the characters though (I tried to find it but couldn't).



Performance issue would be more of a factor of the total number of objects than the number of pages (though the two would have some correlation). I know performance of large forms is being looked at for runtime issue (ie: in Acrobat/Reader). I'm not sure if anything is being look at for design time performance, I haven't heard anything specific but I'm not up to date on what's being worked on for the next Designer. So it's possible, but I'm not sure.



Chris

Adobe Enterprise Developer Support

[wpinegar]

Thanks for the follow-up! Yes, that makes sense. However since I didn't have the Japanese font pack or any Japanese fonts installed on the development workstation then LiveCycle must have used it as a "fallback" font for unknown glyphs. Specifically somewhere in the LiveCycle code must have been detection for what it thinks might be Japanese fonts. I would bet that you are right, if we had the right font loaded on the system then it wouldn't have been an issue.



The performance issues are all with the Designer. There are quite a few objects in my 24 page PDF document. Since many of these PDF pages came from federal forms I imported them into Designer "perserving appearence" so the object count on each page in pretty high. Acrobat reader performs fine with the 24 page form, it's just the Designer that gets pretty slow on some operations.



By the way, do you know if Designer will have better support for adding/removing pages from a document. When I first attempted to assemble the new hire packet 24 page document I opened each federal form individually in Designer and simply copied and pasted the document objects into a new page in a single LiveCycle document to assemble the completed document. I discovered that this didn't work well (objects would paste without the correct fonts) so I went into Acrobat Professional and completely assembled the individual documents into a single 24 page new hire packet before importing this into LiveCycle. This worked very well, but now that I have a LiveCycle document I cannot use Acrobat Professional any more for these types of operations.



I guess my point is that assembing forms from separate documents in a one single LiveCycle document didn't work well just using the LiveCycle development tool. So my question is: are there going to be improvements to LiveCycle so that assembling documents is easier (much like what Acrobat Professional allows) and without flaw. Now that I have a 24 page LiveCycle document I cannot add any more pages onto the document from within Acrobat Professional. So another similar question is: will Acrobat Professional be enhanced to be more "LiveCycle aware" so that it can correctly add/delete pages even in LiveCycle documents. The current limitations with both products as it relates to assembling LiveCycle documents leaves something to be desired. I hope there are plans to correct this.

[Former Community Member]

Well, when you import an Acrobat PDF it creates an enormous number of static text objects. So performance in a form that has been converted will be much worse than a cleaner form that was created from the start in Designer. I know the import process is being look at for the future.



For your other points, I understand what you mean, but don't know of the specific plans for the future as it pertains to these, so I can't really provide any answers.



Chris

Adobe Enterprise Developer Support