Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Andrzejek on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to set font size and type in TXT file thru VFP6/9 3

Piotr Czekalski

Programmer
May 17, 2024
86
PL
Hi all,

is it possible to programmatically apply font to display text files by command Modi Comm File.TXT - preferably when starting program ?

I use "Modi Comm File.TXT NoEdit" command to display reports (text files contents). I manually set font via: Format-> Font and then Edit->Properites->Apply to TXT->OK. After some time VFP assigns a different font to display TXT files. Then displayed reports lose their format. I taught my clients to manually set the appropriate font format and size themselves, but it's a problem. I use Modi Comm commands in programs in many places in code. I'd rather not change that solution.

Thx for help :)
 
What about the idea to use an editbox per page? Or Griffs PDF creation. In the FAQ linked Griff tells you can specify a number of lines per page, I think that's also what you configure for txt file printing in a Generic Text printer, or your report creating a text file will put in CHR(12) for page breaks. So if you find CHR(12) characters in your text files, you can use ALINES to separate pages by using CHR(12) as the parsechar for splitting.

That's exactly what I was thinking. That's what I used to do with printouts in Windows7/10 to old Oki Microline dot matrix printers via "Copy File.TXT LPT1.DOS". For some reason, after printing a few pages, the printout would suddenly stop. Probably some buffer would overflow. Every two pages I closed the printer and initiated printing to continue. It was easy to programing. It's harder with graphics on the screen. This requires ensuring a smooth transition between packages or creating a user interface that allows navigation between packages.
 
Last edited:
Regarding your sample code:

You're not the first one caught unaware by the pitfalls of MEMLINES. It doesn't count linefeeds, mainly, it divides srting length by memowidth, mainly. ALINES will count linefeeds.
 
Inset Chris to code "SET MMEMOWIDTH TO 256 or the maximum value designed for VFP. Then will be corectly. I entered MMEMOWIDTH value 1000 as a test. The number of report lines by MemLines() is correct. I counted manually :)

Aliness is certainly a very good counter tool. Do you know a way to make it not create a GB array of data?

I have checked the library for creating PDFs that you presented. It creates PDF files from text files, but it is not useful for my purposes. It cannot reproduce my font. I do not know what the reason is. The procedure certainly works correctly on other fonts. Maybe my font is not designed correctly. However, when I use "Courier New",10 Acrobat displays only blank screen.

PDFCREATE("TEST.TXT","TEST.PDF",1,"Courier New",10)

Maybe I am doing something wrong?

Example of PDF file.

Screen-10.jpg
 
Last edited:
SET MMEMOWIDTH TO 256
Well, then addd that to your code.

MEMLINES is the correct lines, if text is displayed with added line breaks when a line succeeds MEMOWIDTH, i.e. when a text is displayed with MEMWIDTH as maximum width of lines, but if MEMWIDTH is too low you get a far off count. You want to display a text AS IT IS, not as it would be...
The art of coding is to make code independent of settings (of other users). ALINES is always correct. And while VFP6 does not have the parsechar parameter, it already has ALINES, too. And ALINES only breaks the text into lines at linebreaks, always.
 
Last edited:
Program code corected.

I have added SET MEMOWIDTH TO 256. You can give a higher value (it won't hurt). In my programming environment and in programs codes I have set the value to 256.


Code:
*********************************
* example of displaying txt files
*********************************

***
XStartMemoWidth=Set("MemoWidth")
Set Memowidth To 256
***


XFont=GetFont()

XAt=AT(",",XFont)
XFontName=Substr(XFont,1,xAt-1)
XFont=Stuff(XFont,1,XAt,"")
XAt=AT(",",XFont)
XFontSize=Val(Substr(XFont,1,XAt-1))
XFontStyle=Stuff(XFont,1,XAt,"")

*Wait XFontName+","+Str(XFontSize,2)+","+XFontStyle Wind

IF Empty(XFontName) OR XFontSize=0 OR Empty(XFontStyle)
  Retu
EndIF


****
XFileTXT=GetFile("TXT","File Name TXT")
IF Empty(XFileTXT)
  Retu
EndIF
XBufTXT=FileToStr(XFileTXT)
***


***
XCurFontName  = WFont(1)
XcurFontSize  = WFont(2)
XCurFontStyle = WFont(3)

XCurFM=FontMetric(1,XCurFontName,XCurFontSize,XCurFontStyle)
XEdboxFM=FontMetric(1,XFontName,XFontSize,XFontStyle)

IF XEdboxFM>=XCurFM
  XFontFactor=(XEdboxFM/XCurFM)*1.3
Else
  XFontFactor=1.3
EndIF


XMaxEdBoxHeight=Memlines(XBufTXT)*XFontFactor
***

ob1=CREATEOBJECT("edytor")
ob1.Show()


Set Memowidth To XStartMemoWidth


RETU




DEFINE CLASS edytor AS FORM

ScaleMode = 0
AutoCenter = .T.

BackColor = RGB(255,255,255)
BorderStyle = 3
Caption = ""
WindowType = 1
ScrollBars=3
Visible =.T.


Top    = 10
Left   = 80
Height = 30
Width  = 80




ADD OBJECT textEdit  AS EditBox 
 
 
Procedure Init
 
With Thisform.textEdit
 
  .Value       =   XBufTXT
  .Top         =   0
  .Left        =   0
  .Height      =   XMaxEdBoxHeight
  .Width       =   600
  .Format      =    ""
  .FontName    =   XFontName
  .FontSize    =    XFontSize
  .Visible     =   .T.
  .Enabled     =   .T.
  .ScrollBars  =    0
 
EndWith
 
EndProc
 


ENDDEFINE
 
Why can't you reproduce your font? Isn't it a true type font?

Good question. Ask autor of script about the Courier font from his provided example. I get a PDF that shows nothing.

PDFCREATE("TEST.TXT","TEST.PDF",1,"Courier",10)

Chris, I will finish the project. The interface will be available. The ListBox will freeze with a list of document pages to display. The page ranges are 1-20, 21-40,41-60 etc... After starting the program, the range 1-20 will be displayed.

In conclusion.

For now, the commands "Modi Comm File.TXT NoEdit" and "ModyFile File.TXT NoEdit" are doing their work. At the beginning of the program, you need to use the command Set Resource OFF in the code. Not in the Config.FWP file because there will be problems. And then use the sequence of commands in program code seems optimal.

Code:
Set Resource ON
Modi Comm MyFile.TXT NoEdit
Set Resource OFF

This works stably. Solves the problem for now. The editor does not lose font setting and ScrollBars are visible horizontally and vertically..
The critical point was the FoxUser.DBF file. Limiting access to this file to a minimum improved the situation.
 
Last edited:
The config.FWP file must be called config.fpw and the line in it to set resource off is RESOURCE=OFF, not SET RESOURCE OFF
Otherwise that seems to do the job with the least effort, yes.

It's obviously not important anymore for you to get Griffs pdfcreator.prg in the FAQ mentioned above working, but I can attest it works, not only the download URL is still available, the function in the PRG is respecting the font parameter etc. It hasn't become outdated, which could always happen to old FAQs.
 
Last edited:
It's obviously not important anymore for you to get Griffs pdfcreator.prg in the FAQ mentioned above working, but I can attest it works, not only the download URL is still available, the function in the PRG is respecting the font parameter etc. It hasn't become outdated, which could always happen to old FAQs.

Absolutely not Chris. I downloaded the ZIP File. I wrote that it probably works with other fonts. And yes .... it work. It hangs with my font. Acrobat Reader displays the message:

Font contains bad /BBox

If I use any PDFPrinter for screen presentation., everything is OK. Font issues are handled by the printer drivers. I can't fix this font. The author has been dead for a few years. I have no knowledge about details of that font. I've been using it over 25 years. There have never been any proplems with graphical presentation reports on screen in PDF format or printer. This is the first time I've seen such a message during conversion using this PDFCREATE() tool. The tool is certainly great, but for now it's useless to me. I have old diskettes with my fonts. When I have time, I'll check their contents. Maybe there is some description.

I'll add for clarification that the original font installed with VFP9 FoxFont also causes a similar error on my computer. I checked Courier 10 again. In forms with standard Asci characters PDF is OK.

Ekran-11.jpg
 
Last edited:
Okay, it's a start to know the error/warning notice about "BBox". There are font editors out there, so you could try to fix it up.
Another test run, that you could do is use ShellExecute of a txt file with "print" action and setting it to print with a PDF printer instead.

Code:
DECLARE INTEGER ShellExecute IN shell32.dll ;
  INTEGER hndWin, ;
  STRING cAction, ;
  STRING cFileName, ;
  STRING cParams, ;
  STRING cDir, ;
  INTEGER nShowWin
    
ShellExecute(0,"print","some.txt")

But before testing this out, do it manually from Windows eplorer, perhaps. Since a txt file won't store the font to use, that's what would need to be given by configuration of whichever application is associated with txt files and thus also printing them, I think. By default notepad, with the difficulties about long files you know. But configuring your font there would make it convert with that font. If that's still causing the same Acrobat Reader error, you know more certain it's the font. But how about trying other readers, too? To pinpoint where the actual problem is.

Googling a bit it's not a rare error, the meaning of BBOX seems to be bounbding box, so for some letter of the font, some stroke of a letter leaves a bounding box that's the roughest measure of the size of a character saying it will be completely within that box (rectangle), and that could be corrected with a font editor. I also only found this ion conjunction with Acrobat, so other PDF readers might not be as overly correct and allow a overflow.
 
I found a lot of information about this error. Sometimes reinstalling the font helped. In my case, the error occurs in FoxFont installed with VFP9, as well as in Font developed by my colleague. Printing from VFP to PDF printer, as I wrote, is correct. Acrobat reads correctly documents. There are repeated comments on the web that this is an AcrobatReader error if PDF files are created using external procedures. Many people have problems with this. Thank you for your help. If we manage to solve the PDF problem, another problem will appear - PDF horizontal scrolling. This may turn out to be an insurmountable barrier, unless someone has developed it in VFP :). I propose to close the theme of the PDF creation tool. It takes too much time. We will not adapt font FoxFont developed by Microsoft to PdfCreate(). This may be one unfortunate character in the font matrix. This is the waste of time. PDF printers process it without any problems.

I am very sorry, but the end beginning of the year is a lot of work on payroll and accounting programs. Changes in regulations, tax documents and reports etc. In my country, the deadlines for sending the declaration are are until the end of January. Everything must be ready by mid-January. I am working on XML schemas for declarations, reports, etc. I will definitely get back in our main topic.
 
Last edited:
the deadlines for sending the declaration are are until the end of January. Everything must be ready by mid-January
Good luck getting done soon enough.

Just some more thoughts you can better confirm or not than me: PDF printers would also print landscape pages, won't they? A txt file has no page formatting included, but txt put into a word file would. And since your text files in nature are reports, still, they do have a page structure, don't they? Or are they intended for display only, and can have an endless nature like a receipt of a POS system, aka a "slip". Are these txts ever printed, is it just a preview, you're aiming for? Depending on answers to those question I would know how to set priorities.
 
Text files have exactly the same appearance as printer printouts. They consist of ASCII characters. For this reason, they can be opened using Modi File. Text files are imported into the Memo field in the DBF table and then printed to the printer using the "? MyMemoField" command. Narrow in the vertical layout, wide in the horizontal. Text files are created using the commands: Set Printer To File.TXT. Print lines using the commands as in dBase (in great simplification). @ Row, Col, Say String. Exactly the same appearance of reports is on the screen and the printer. All this is automated, but this is a general mechanism. I do not use Report From .... The line numbers start from 1, for example, and then are increased as needed. After exceeding a certain number intended for the page, they start again from number 1. Then starts a new page.
 
Last edited:
You don't seem to get the gist of my questions.

I already knew your requirement of horizontal scrollling. You still didn't answer if you have pages or not, pages are not only a thing for FRX reports. As you create texts especially with@ row.col Say string, there's a reason to use coordinates, isn't there? And one possible reason is to have offsets going into page X. Then you could also easily create single page txt files and paste them into a word file (programmatically) to have a landscape page document for printing by PDF printer for the preview display.

If it's just any horizontal width however wide? It may be, you have no pagination, then do you print rotated 90 degrees on endless paper or with small font to not exceed the landscape paper width when printing? I only know what you tell.
 
Last edited:
Good, then it will be doable to do a 2 step process. Maybe, before I tell the two steps: The basic idea is that PDF printers are still page oriented printers and don't create endless pages. Griffs PDF creator had a number of lines parameter for that - the simplest way to define pages in text only printing.

So while that fials for you, not only because of the font specifics, it could work out to create word pages (landscape, I assume) and then use PDF creation from there.

So
1. create single page text files instead of one whole report file, maybe in a folder
2. Create an empty word document and a little bit of OLE automation code to create pages and read and paste in the single page text files into them.

Maybe you also already do this in the report processing, whatever. I know this will not just be a small change to the reporting, but might be worth it as you could also just display the word document for previewing, check out, if there are issues with the font in Word already.
 
Ok, Chris, as I wrote earlier. I can't participate in experiments until the end of January 2025. You have Microsoft FoxFont installed. This font also reports incorect BBox .

I will finish the code that I presented here. It will take me some time due to my professional activities. I like to experiment, find solutions, bugs and fix them :cool: so i will be back.
 

Part and Inventory Search

Sponsor

Back
Top