#64 2018 US_1040 Dependents, Occupations, Refunds not showing in PDF output

[R. C. Pao]

I copy and pasted the keywords you added to f1040_meta.dat into US_1040_example.txt, but the PDF output is not showing my entries.

I probably did it wrong as I'm not good with column/positional text file formats. Attached is my attempt.

[Aston Roberts]

Two things:

1. Those tags need to be added to your output file (US_1040_example_out.txt, not the input file) and then processed by the universal_pdf_file_modifier.
2. There should be no colon ":" following them.
   For example, "YourOccupat:" should be "YourOccupat".

But this bring up an idea. Maybe we should add a general catch-all tag for input files, that let's you enter any custom tag-names to be passed straight out to your PDF. This way you could maintain such optional data, or even your own custom items, in your input files. Will consider adding this feature to an upcoming release.

Thanks!

[Aston Roberts]

Due to this and similar requests, a new keyword is enabled in OTS versions starting with 16.03 and above. The new "MarkupPDF" commands can be added anywhere within your tax Input File (via a text editor for now). This enables you to add your own markups that will show up on your PDF output files. And since you can maintain them in your input file(s), they will not get over-written when tax-programs run. Instructions and examples are show under OTS's Input Format web page.

[John Morgan]

I have been playing with this new function for 2 hours or so and I very much like what I see! This is going to make editing the PDF after all the other work is done obsolete. Let me give you some quick feed back on what I am seeing and perhaps you can show me what I am doing wrong or I can point out something you have overlooked.

It took me a few minutes to figure out where “OTS's Input Format web page ‘’ is but I got there and the instructions seem quite clear.
My first test was to fill in the NJ County / Municipality code which is a 4 digit number. After looking at the NJ_1040_meta file I discovered there already is a field (CountyCode) for this data but I couldn’t find a way to populate it. So I went on with making my own.
I put
MarkupPDF( 1, 159, 309 ) CountyMuniCode = 0805
In my input file and let ‘er rip. It printed some numbers in about the right place which pleased me but the numbers were jammed together and not in the boxes. Of course MarkupPDF didn’t know that each character got it’s own box. I broke it into 4 commands ,each with it’s own x/y and a 1 character value.
This is where it became evident that numbers would be a problem. I can put an “a” in the box but if I try to put an “8” in the box I get “8.00”. I tried putting quotes around the 8 but that doesn’t help. This is where I am at the moment.

One reason I am writing this is so you know someone else is trying to use the feature you put so much work into. I still have lots to learn.
Thanks!

[Norman Leet]

John,
I tried this in the NJ example input.txt file, at the end of the file:
MarkupPDF CountyCode 0805
The numbers centered nicely in the boxes (I suppose this ithe 20 font size for CountyCode in the meta.dat file), but the leading zero was truncated, and 2 zeroes were added to the end.
Would seem to need to treat the entry like a ZIP Code, but not sure that can be designated selectively for a particular entry.
-Norm

[Norman Leet]

Hmmmm....."20 font size" is more likely "20 character spacing".

[Norman Leet]

Reaching way beyond my level of competence, would adding a check for "MarkupPDF" in universal_pdf_file_modifier.c at line 835 cause OTS to always treat a MarkupPDF input entry as a non-numeric entry ?
-Norm

[Norman Leet]

Upon reflection, a better idea might be to enclose the value of the label (for a MarkupPDF) in double quotes. Then arrange for universal_pdf_file_modifier.c to trap the leading double quote as a discriminator for skipping any any adjusting/formatting for a numeric value. You would then also have to truncate the trailing double quote, if it is there. I do not see double quotes being used elsewhere in the input.txt or out.txt files, so I presume there are no conflicts with use of the double quote for this purpose.
Strictly speaking, I think that one would only need to use the double quotes for a numeic value. Alpha-numeric values look like they would cruise through without an issue.
-Norm

[Norman Leet]

I offer up this strictly to stimulate conversation. It is by no means complete.
I edited the NJ example input.txt file by adding at the end of the file:
MarkupPDF CountyCode = "0805
Note the one double-quote.
I also made a one line change to universal_pdf_file_modifier.c
823c823
< if ((showdpt) || (value[j] != '.'))

---

   if ( (value[j] != '"')  && ((showdpt) || (value[j] != '.')) )

The CountyCode shows up as 0805, centered in blocks in the pdf file.

[Norman Leet]

This particular issue was resolved in release 16.04, using double quotes in the input.txt file, i.e.
MarkupPDF CountyCode "0805"
If leading/trailing quotes are inadvertently used in the 'iditems" (like name or zip code or SSAN), those double quotes are also scrubbed before the PDF output. A nice consistency for first time users.
For the extremely lazy and daring, single word entries can be done with just the leading double quote.
Very nice implementation !
-Norm

[John Morgan]

In 1040 Schedule C, there is a field ActivityCode which is a numeric code that fills into little boxes, just like NJ1040 CountyCode. ActivityCode seems to work fine. I even put a leading zero 0n the number and it printed fine. I don't see any big differences between ActivityCode and CountyCode except one works fine and the other doesn't. There are things going on here that I do not understand (situation: Normal).
John