Page limit on printing from Do File editor?

[ghoetker]

Using Stata 15 on MacOS 10.12 (Sierra). I've been trying to print a long do file from the Do File editor and to my surprise found that it would only print the first 30 pages. Tried printing to multiple targets, so I think it is Stata, rather than the printer. Has anyone else encountered this? Is it Stata's subtle way of telling me my do file is too darn long (I agree, but would like to have the option to print it, regardless). I dealt with it, imperfectly, by cutting and pasting into a new file, but would appreciate any insights? Have I missed a preference somewhere? Thanks.

[William Lisowski]

Welcome to Statalist.

Using Stata 15 on macOS 10.12.6, I created a do-file with 30,000 short display commands. From the Do-file Editor window I hit the printer button; the preview in the print dialog box told me there were 64 pages, and I selected, from the PDF dropdown menu in the lower left corner, Open PDF in Preview, and indeed a 64-page PDF did open.

Does the print dialog box confirm your expectation of exceeding of 30 pages? Are you able to create a PDF that passes the 30-page cutoff?

Perhaps my failure to duplicate the problem lies with the total size of the file measured in bytes rather than lines - my display commands were short.

A discouraging resolution, I realize. If you can make the do-file available to me, I'd be glad to try using your file - although I'd limit my testing to creating a PDF, to save paper, and since the result is a long PDF the printing problem is likely not a Stata problem - or in any event, the PDF is a workaround to printing.

[Chinh Nguyen (StataCorp)]

I tried this on both Sierra and High Sierra and had no problem printing (to a PDF) files with 90+ pages. I created the document by opening regress.ado and copying all of the lines and pasting them until I had over 4000 lines. I also added a unique last line so that I could be sure all lines were printed.

When you say print, are you really printing to a printer? What happens when you print to a PDF?

[ghoetker]

Thank you William and Chinh for the quick answers. I've put the file in question at https://pastebin.com/2Ri4PsSQ. (And, yes, I know it is rather a mess. My involvement is largely to help clean it up.) To give more detail, under the Quick Preview of the Print Dialog it shows "1 out of 30 pages" (see https://www.dropbox.com/s/xn7ny5d2lo...blems.png?dl=0 for an image showing what I mean). No matter which printer I choose and whether I ultimately hit "Print" to go to the physical printer or "PDF/Save as PDF", only the first 30 pages area printed/saved. The last line to be printed is consistently line 655.

Thanks of the help and please let me know if there is any other information I can share.

[Red Owl]

George,

I put your text into the public domain Notepad++ developer's editor (https://notepad-plus-plus.org/) and changed the settings to show character codes.

This is what I see near line 655, which you identified as the potentially offending area.

It is difficult to see in this screen shot, but, if you look closely, you will see that there is an anomaly at the beginning of line 655. It appears that there is either a space or a non-displaying character preceding the tab. All the other tabbed lines around this do not have that space or non-displaying character. You may need to zoom this screen shot to see what I'm describing.

If you have not already done so, you might try deleting line 655 and retyping it clean to see if that removes any offending hidden character that might be interfering with printing this document.

Red Owl
Stata/IC 15.0
Windows 10 (64-bit)

[William Lisowski]

I downloaded the file and loaded it into the Do-file Editor and was able to create a PDF of the entire file.

If you have not already done so, it would be a good if you would download the file you uploaded and confirmed that the downloaded copy also exhibits the same behavior as the original.

When I hex-dumped the file, it showed a simple space before the tab. The earlier line 190 appears to have two spaces before the tab, and line 669 also has a single space before the tab.

I'm concerned that the upload/download process scrubbed some other character into a simple space that "solved" the problem.

[Chinh Nguyen (StataCorp)]

I agree with William, try downloading what you uploaded. I was able to print (to PDF) your file just fine. In addition, my print preview of the first page is complete while your screenshot shows half of the text on the first page is missing.

When I print, it says it's printing 30 pages but I confirmed that there really are 30 pages and that the last line of text in your file is the last line of text in my printed file. I suggest you zip up the text file and put it up so we can try again. It's possible that your text file was modified when it was uploaded and zipping it up should prevent that from happening.

[William Lisowski]

I had the same experience as Chinh Nguyen did with Glenn's do-file, but didn't mention it. When printing from the Do-file Editor, the file is 30 pages head to tail. In Stata Preferences, my font for the Do-file Editor is selected as Menlo Regular 12 point. I attributed the difference to a different choice of font and/or size in Glenn's setup, although the coincidence of "page 30" seems a bit strong, and 655 lines, even with some wrapping, on 30 pages comes to about 22 lines per page. I think perhaps I don't understand Glenn's experience as well as I thought I did.

Glenn, I agree with the suggestion from Chinh Nguyen that you "hide" your do-file within a ZIP archive so that it appears as (what I used to know as) a "binary file" to the upload and download, and no attempt is made to mess with the contents of the file, as is often the case with files recognized as containing text (for line-end conversion, for example).

[ghoetker]

SOLVED!! Thank you everyone for your excellent suggestions. I'll describe the solution in case it helps others with similar problems.

tl;dr version: Sometimes trashing the preferences file fixes things.

When Red Owl and Chinh's suggestions didn't help, I got a lead from Chinh and William's comments that made realize that the problem might not quite what I thought it was.

Like William's, I was also using Menlo 12 point, but the end of my 30 pages is definitely NOT the last line in the file. Rather it is part way through section D of the file.

So, at that point I wondered if it was something to do with the fact that I only seem to be printing on the top half of each page (which continues for every page, not just the first). Loaded up a totally different long do file and tried to print. Same issue of half-page only, cut off before the end. Made a brand new file. Same result. Made a new printer. Same problem.

So, then I created a new user, logged into under it, opened Stata, created a long do file, and it printed just fine. So, option one is that have something running in my main account that is conflicting with Stata's ability to print. This is really odd, as I haven't had any print problems from any other program, something I've just confirmed with Word, Pages, Textmate, Numbers, Atom and Safari.

Option two is that something in my Stata preferences or settings has become corrupted (or I something stupid to it), since I think those would be created anew for the new user. Back in my main account, I quit Stata, moved the files ~/Library/Preferences/com.stata.stata15.plist and ~/Library/Preferences/com.stata.stata14.plist (a left-lover, I guess) to the desktop, compressed them, trashed the originals and emptied the trash. This way, Stata would create a new preferences file with it next loaded, but I could get the old one back if needed (probably overkill). Stated Stata, re-opened the problematic file and it printed just fine. 30 pages, but filled top to bottom and ending with the last line of the file. "Yipp" and, dare I say, "ee!"

I haven't found any major problems yet, although I suppose one shouldn't trash preferences files as a first resort.

Thank you again, everyone! What a great community!

[William Lisowski]

Wow. Thank you for closing the loop on this. I'm pretty sure we haven't seen one like this before on Statalist. That was a very nice approach, creating a new user account to narrow the focus to something specific to your account.

I'd like to think that had I heard that only the top half of each page was used for printing, I might have concluded that the problem was indeed Stata rather than the do-file itself, and then in a burst of blinding insight would have suggested the preferences. But I'd like to think I'm still 24, and I expect that neither of those thoughts is correct.

[Richard Williams]

I often think it would be easier to buy a new machine than it would be to debug whatever is wrong with the old one. ;-)

[Chinh Nguyen (StataCorp)]

Our usual first suggestion for difficult problems is to create a new user account and see if you can reproduce the problem there. We had one user years ago who's Stata would keep crashing. After they saw that Stata was fine running in a new user account, they narrowed it down to an out of date version of Dropbox.