Question PDFInclude 3.3.3 -> Error 560

ezequiel

ezequiel

Member
Hello, we need to use a PDF form for filling some fields and generating a new pdf.

I've created a PDF file ("PruebaForm01.pdf") with one only field ("codcli"), using ArialMT font, size 10.

When I run my program, I receive some errors. The first is "Entry 4 is outside the range of list /FontName/BAAAAA+ArialMT. (560)"

I don't know waht is that BAAAAA, I guess it has to do with arial.afm but I really don't know.

I hope you can help me, we use Progress 9.1C, Windows 8.1 workstations.



The code is:
Code: 
{pdf_inc.i}
DEF VAR cPdfFile AS CHARACTER.
FIND cliente WHERE cliente.codcia = "001"
  AND cliente.codcli = "109690"
  NO-LOCK NO-ERROR.
IF AVAILABLE cliente THEN DO:
  cPdfFile = "E:\AquiPromec\pdf\Form\PruebaForm-" + cliente.codcli + ".pdf".
  /* Definir PDF nuevo */
  RUN pdf_new ("Spdf",cPdfFile).
  /* Abrir PDF template */
  RUN pdf_new_page ("Spdf").
  RUN pdf_load_font
  ("Spdf",
   "ArialMT",
   "c:\windows\fonts\606.ttf", 
   "src\pdfinclude\arial.afm",
   "").
  RUN pdf_set_font ("Spdf", "ArialMT", 10).
  RUN pdf_open_pdf ("Spdf","E:\AquiPromec\pdf\Form\PruebaForm01.pdf", "Cli").
  RUN pdf_use_PDF_page("Spdf","Cli",1).
  RUN pdf_fill_text("Spdf", "codcli", cliente.codcli, "").
  RUN pdf_close("Spdf").
END.
 
Hello, yes it's wrong. In our defense I can say we have already bought OE11.x but current system is still working.

I'm uploading a zip with our complete pdfinclude directory.

The error appears in line 19, when trying to open the tempate PDF file.

My guess was it had to do with the font, but I have tried with others and it's the same problem.

Somewhere, PDFInclude searches a font called "BAAAAA+ArialMT" and there is none, there's only "ArialMT".
 

Attachments

Have you seen 11.x in action at all? You are in for a lovely surprise in terms of performance, assuming you move to Type II storage areas, and some of the DB Management tools are so much quicker too.

Back on topic - can you start your session with the -debugalert option? Then you should be able to easily stack trace the error you're getting. Compile the code with debug listing to get the real line number of the fault. Might point you in the right direction at least. :)
 
About 11.x, well, the assigned Progress partner for my country is not doing a great job in capacitation. And we need it.

About -debugalert, I'll give a try today

Thank you, Cringer.
 
Well, I haven't be succesful with -debugalter because it tries to read the .hlp and in my workstation, for some reason, Microsoft KB917607 doesn't works.

So I need to solve this first.


I will suggest your suggestion to my boss....
 
It wasn't a serious suggestion ezequiel. I'm not working as a consultant so I couldn't legally do it - it would be a breach of my current employment contract. Sorry - I forget that English humour doesn't transfer well to other cultures!
Not sure why it's trying to read a .hlp file. Where did you put the -debugalert parameter? At what point did you get the .hlp problem?
 
If you are trying to use the PDF Include provided arial.afm, you may want to try to use one of the various free ttf to afm converters to generate your own afm for the 606.ttf file you are referencing.
 
ezequiel said:
Well, I haven't be succesful with -debugalter because it tries to read the .hlp and in my workstation, for some reason, Microsoft KB917607 doesn't works.

So I need to solve this first.
Click to expand...

You need -debugalert (not -debugalter) - I have never seen this require .hlp, but then I'm not using Windows 8.1.

If I compare the 'latest' version of pdfinclude on oehive with the 3.3.3 version on sourceforge, pdfextract.p does contain a change (dated 2010-02-11) in ProcessFontDescriptorDictionary (in pdfextract.p):

old:
Code: 
          IF ENTRY(4, text-temp, " ") = "R" THEN DO:

new:
Code: 
          /* 11-FEB-2010 jcc: start */
          cEntry4 = "".
          cEntry4 = ENTRY(4, text-temp, " ") NO-ERROR.
          IF cEntry4 = "R" THEN DO: /* 11-FEB-2010 jcc: end */

But you really need to get your debugalert fixed - debugging without a stacktrace is like making love to a beautiful woman (;-) just had to use that Swiss Toni quote)
 
Status Report.

Stefan: Never heard about Swiss Toni, I've just googled it.
"-debugalter", that was a typo, sorry.

I've just repaired my .hlp problem.

"My" pdfextract.p has that correction in one case but there are many others in "old" version. And there is no remark like "/* 11-FEB-2010 jcc: start */".


LarryD, generate an specific AFM, great idea, I'll go for it.
 
sorry for the shameless plug but you could try free docxfactory project.

docxfactory supports practically every 1d and 2d barcode in the world.

basically you would just add a field {MyField pdf417}

disclosure, i wrote the project.
 
joey.jeremiah said:
sorry for the shameless plug but you could try free docxfactory project.

docxfactory supports practically every 1d and 2d barcode in the world.

basically you would just add a field {MyField pdf417}

disclosure, i wrote the project.
Click to expand...

I got requirement to print the invoice in progress using PDFInclude ,I have to print the invoice number as in the form of barcode(i.e.,PDF417) .
I tried using Code39 barcode that has working fine and also I was able to scan it but the requirement is to use PDF417 barcode and generate a PDF which has invoice number in the form of 2d barcode( pdf417).
please help me to do this.
 
hi Rashi,

there is no built-in support for pdf417 in pdfinclude

so you'll have to find a pdf417 tool that creates an image that you can insert into your document.

hope this helps!
 
I dont see the point in PDFinclude in a windows enviroment. Just use com-handles and open excel/word. You can use saveto and save as a PDF anyway, and it gives you more scope for layout etc.

Oh and have fun when you upgrade to windows 10. It destroyed our V9 application.
 
Last edited:
Maybe I'm biased but I would strongly recommend against com-handles. Com-handles are windows only and requires Microsoft Office to be installed, creating even moderate sized documents can take minutes, resource intensive and does not scale, making it a bad server side solution and is one of the main reasons OpenXML (.docx, .xlsx, etc.) was created.

Unfortunately, V9 is not certified for Windows 10 but V10 is certified and supported for Windows 10.
 
You must log in or register to reply here.
Back
Top