Set default margins for opening text files RRS feed

  • Question

  • I have an automated application that depends on Word to correctly format text files so they can be converted to PDF for parsing. The formatting of these files is exactly what you get when you open the text file in Word.

    I found out how to edit the Plain Text style to modify the default font used. However I am unable to find a way to get the default margins to be anything other than 0.92". Updating the defaults in Normal.dotm has no effect on opening plain text files. Exhaustive Google searches have turned up nothing.

    If I change my margins to 0.25" and default font to Courier New 10 instead of 10.5 the file is formatted perfectly for my application. However since it is part of a black-box automation, a macro-based approach will not resolve it. I have to change the default behavior for how Word opens a text file.

    Can anyone point me to where the default margins for plain text conversion are set? Thanks!!

    Tuesday, February 25, 2020 3:02 PM

All replies

  • Plain text files have no margins. Indeed, they know nothing of page layouts. A plain text file opened in Word will necessarily adopt whatever margins and font settings have been set as the default for the template being used for that purpose. So, if you require particular settings to be used, you need to modify the template used by your application, which may or may not be Normal.dotm and, even if it is Normal.dotm, you need to modify the Normal.dotm used by your application. All this assumes, of course, that your application isn't changing the page layout to suit what the developers decided it should be. FWIW your 0.92in is probably an actual 2.0cm.

    Paul Edstein
    [MS MVP - Word]

    Wednesday, February 26, 2020 11:02 AM
  • Already modified Normal.dotm. When I create a new blank document the margins are all 0.25". There does not seem to be any way to set the default margins for opening text files though.

    Interestingly the "Plain Text" style doesn't appear in Normal.dotm when I open the template directly. However I am able to edit the Plain Text style in Normal.dotm when I open a text document and edit the style applied to the text. I feel like this margin issue is something similar where the defaults for plain text are different than the defaults for regular documents and exist in some hidden place.

    My application is just a Word automation so it is not a factor in this. If I can get the file to render correctly when I open it in word then my issue is solved so forget about the application.

    Wednesday, February 26, 2020 11:22 AM
  • The 'Plain Text' paragraph Style has no indent settings and cannot affect the page setup - margins or otherwise. If you open the Normal.dotm template used by your application and modify the default paragraph Style from 'Normal' to 'Plain Text', the inserted content will be automatically formatted in that Style. Likewise for the margins. If your application continues to generate output with the wrong paragraph Style and/or margins, the issue isn't with Word but with your application.

    Paul Edstein
    [MS MVP - Word]

    Wednesday, February 26, 2020 11:04 PM
  • FWIW I see the same problem - it doesn't matter what the margins in are, when you open a .txt file as Plain text Word imposes another set of margins (66.7pt = 0.93in on the left, 66.75pt on the right. Not obvious in which units those would be round numbers, but I notice that for US Letter Layout, those margins +Courier New 10.5pt give you almost exactly 75 characters per line, which may have some significance in the U.S.).  As far as I can tell, it has been this way since Word 97, except the imposed margins have not always been the same.

    I don't know of a place where you can set those margins either. I don't see any evidence that there is any special template (cf. NormalEmail.dotm) that Word uses for .txt files.

    But I am not sure what you are looking for when you say "black box". Probably not worth arguing about the definition, but if for example you need your application to run on an arbitrary system, I don't really see how you could rely on being able to make a change to Normal.dotm, for example.

    So perhaps it would be easier to try to pin down what your application can rely on being able to do, and what exactly you have to avoid doing.

    e.g. AFAICS you must be doing some COM automation of Word in order to be able to save your .txt as a .docx. And if you're doing some automation, it's not obvious why you couldn't also

     a. open the .txt file

     b. apply new margins

     c. apply a specific font and size to the entire text (or modify a style and apply that, or whatever)

     d. Save and close as a .docx

    Or if you actually *want* the .txt file to take on the characteristics of the local normal.dotm, you might automate Word to 
     a. create a new blank Word document based on Normal

     b. insert the .txt file into that

     c. make any layout changes you want

     d. save and close

    Also it's not obvious whether you are using Word to create the PDFs or using something else for that.

    If you're using another approach it might help to have an outline of that.

    Otherwise, I think you would probably have to use something like the .NET Open Xml SDK to create a .docx with the necessary layout, e.g. define the styles you need, and perhaps read your .txt files line by line and apply the necessary paragraph styling. Not sure whether you could guarantee that that approach would deal with non-ANSI/ASCII characters the same way that Word would though. There's another approach using an Open XML "AltChunk" to include your text file. That might be feasible if the correct formatting could be applied to the entire content of the AltChunk. But that would still require that the document was opened by Word at some point as I don't think anything else really understands AltChunks.

    Peter Jamieson

    Thursday, February 27, 2020 10:32 AM
  • Unfortunately it is not possible to consider approaches that replace the automation. It is a third party dll that is already integrated into my software that effectively opens a TXT file in Word and saves it as a PDF. The PDF I get depends on the default layout for text files. I can instruct my software's users to edit their Normal.dotm or any other necessary settings in order to perform this task, but I can't replace this module in the already deployed solution. The only solution that will work for me is to change the default default margins used when a text file is opened in Word. 99% of my users do not require this function so it is not a big deal to perform a few extra setup steps for these few users as long as it is possible.
    Thursday, February 27, 2020 11:27 AM
  • FWIW I see the same problem - it doesn't matter what the margins in are, when you open a .txt file as Plain text Word imposes another set of margins (66.7pt = 0.93in on the left, 66.75pt on the right.

    OK, I hadn't thought of that. Evidently, Word doesn't use Normal.dotm for such files.

    A workaround would be to create a document or template with the desired page layout containing a fixed-width table - formatted with the desired paragraph Style - and an INCLUDETEXT field pointing to a generic text file's name in a designated folder.

    If the application that creates the text file can be configured to output them to the designated folder with that generic file name, opening the document (not the text file) will automatically result in the text file being imported and formatted as desired. Saving the document as a PDF with whatever name is required should achieve the desired result.

    Paul Edstein
    [MS MVP - Word]

    Thursday, February 27, 2020 11:42 AM
  • Got it. Can you preprocess the .txt file in any way before the third party dll gets to process it (i guess not, but have to ask!)

    Peter Jamieson

    Thursday, February 27, 2020 12:50 PM
  • Now back in a position to check some things properly.

    I haven't quite pinned this down yet, but the situation seems to be approximately as follows:

     a. When it opens a .txt file, Word takes the top and bottom margins from Normal.dotm, but it calculates the right and left margins using some properties of the font you choose for the Plain Text style.

     b. It then uses the Courier New font anyway, probably using the size that you chose in the Plain Text style.

    I can't remember the correct font terminology now but ISTR there is something like an "x" width, which is the width of an x character in a given typeface with a given font size. I think Word probably does a calculation based on something like that width and the font size.

    So if for example you choose a really wide font such as Broadway, you get much narrower margins for a given point size than you do if you choose a narrower font such as Courier New.

    So it seems there may be two possible ways forward: either work out what margins Word applies for the Courier New font at the size that you want (e.g. 10 rather than the default 10.5), then use negative left and right indents to adjust the paragraphs so that the document *appears to have*  0.25in/18pt left and right margins.

    e.g. for an A4 document, if I choose Courier New 10pt for both the Normal and Plain Text styles, when I open the text file, the left and right margins are 0.8in. If I set the left and right indents of the Plain Text style to -0.55in then the document looks as if it has 0.25 in left and right margins. Whether your 3rd party .dll will generate the output formatted as you need based on that, I cannot tell but that's the route I'd try at this point.

    The other possibility if the margins really have to be 0.25in would be to try to find a font that resulted in 0.25in margins when you set the Plain Text font to that font at 10pt. But that doesn't seem very robust unless you can be sure that that font is installed or unless you can create your own font to achieve that objective.

    As I said, I haven't really worked through all the detail on this. For example, I haven't checked whether Word will always use Courier New regardless of which font you actually specify for the Plain Text style, or whether it will choose another fixed width font in some circumstances (e.g., if you specify one). Nor is it completely clear whether both the Normal and the Plain Tet styles need to be set up the same way, and so on.


    Peter Jamieson

    Thursday, February 27, 2020 4:22 PM
  • @Paul, yes, we're in "it's Normal, Jim, but not as we know it" territory. Any contribution from the MS dev team that explained what exactly their code did would of course be helpful.

    Peter Jamieson

    Thursday, February 27, 2020 8:53 PM
  • Did you make progress on this front or go a different route?

    Peter Jamieson

    Tuesday, March 3, 2020 11:02 PM