HexaPDF glyphs missing as of Version 0.20.2 - ruby-on-rails

I'm using HexaPDF to read a file with an AcroForm and fill in this form's fields using the following code:
#acro_form.field_by_name(fieldname).field_value = value
Up until version 0.20.1 this worked fine. As of version 0.20.2, I get this error: HexaPDF::Error (Glyph for "2" missing) on trying to generate the document. The glyphs for all numbers, and for all lower case letters except a, b, and c cause this respective error.
This problem only occurs in my dev setup on Windows 11, not on Linux.
#gettalong or anyone else who might be able to help: Thx in advance!

With the help of #gettalong I figured out the problem:
Some of the text in data/hexapdf/encoding/glyphlist.txt appears to be automatically processed by Windows, inserting line and page breaks in this file which should not be there, and causing other changes to the file's encodings.
I resolved it by editing the above file as follows:
Remove extra paragraph and line breaks and potential invisible characters on entries for controlFF, controlVT and controlSO
Set codes (the part after the semicolon) for controlSUB to blank
Remove blank space on "controlBEL; ", changing this line to "controlBEL;"
Ensure there is a blank space on space, i.e. the line must be "space; ", not "space;" and ensure there is no additional invisible character there.
Save the file and restart server.

Related

Delphi - My debugger seems to be out of sync with the source code [duplicate]

Since yesterday, all blue dots (compiled lines) in my source code are shifted with one line up.
So, the first dot starts at 'var' instead of 'begin' and the last dot is one line before the last 'end' of a function.
I deleted all files (starting with DCUs) except DPR, PAS, DFM and DPRJ and recompiled. But the dots are still shifted.
How can I fix this? It makes the step=by-step debugging almost impossible.
It could be that the file is corrupted so that you don't have proper line end combination (#13#10) on one line. Is the "one line up error" throughout the file or does it start somewhere in the middle of the unit?
Beginning with Delphi 2007 (maybe already Delphi 2005) you can check the line ends in your code by enableing checkbox Show line breaks in Tools - Options - Editor options - Source options. The line breaks look like this:
As you can see, a CR on its own is not considered a line break and messes up the synchronization of the executable line dots
Try closing Delphi then deleting all *.identcache files.
I have a batch file at the root of my Delphi projects directory that recursively deletes all identcache files.
Try This:
Open the unit in an editor with capabilities to change codification, like Notepad++.
Code/save the file as ANSI.
Open or recharge the file in the Delphi IDE.
The dots must be in the right place.

SQLWindows - How to check Line Number?

I am new to SQLWindows IDE and I need to edit a number of SQLWindows applications. I am using Version 3.0.0 of the IDE. I am facing trouble finding the line number of a particular line of code. Is there any setting or way to know the line number of the code? Generally IDEs provide the line number, but I am not able to see any line number details in the [Outline] mode. Kindly help!
SQLWindows doesn't use line numbers at all.
If you want to change similar code lines in several files, I suggest getting acquainted with the CDK, which lets you write applications that alter .app/apt/apl files. Unfortunately wasn't able to find a "Starter Guide" on Google.
Im guessing you have corruption in a apl file ? If so save the file as 'text' , ( never save as Binary i.e. 'Compiled' or 'App' always save using the 'Text' option ) then re-open it. 9 out of 10 any line number errors fix automatically this way . Once you have saved as Text , you can open it and edit it ( carefully ) in Notepad++ .
Its very unusual to need to know a line number....why would you possibly want to know it ? If you explain more , there may be a better workaround ( there always is )

How to reproduce this Code Completion bug?

I'm having a bug on Delphi XE2 (Update 4 Hotfix 1), which reproduces many times on the legacy project I work (it evolved from D6 to D7,D2006 and finally XE2), but I didn't know how to trigger it in a smaller project.
The latest time, it triggered on creating an event handler for a "hidden popup" on the app. When I click on the menu option to create the Click handler this happens.
pprocedure TMainForm.Blablabla1Click(Sender: TObject);
begin
end;
rocedure TMainForm.FormActivate(Sender: TObject);
You can see that the IDE inserted the new code INSIDE the declaration of the next method... But it's not all.
Almost all times, on the DPR, code gets mangled too:
AApplication.CreateForm(TDM_DataAcc, DM_DataAcc);
AApplication.CreateForm(TMainForm, MainForm);
pplication.CreateForm(Tfrm_login, frm_login);
f frm_Login.CanLogin = mrOK then Application.Run
(It's almost like that, I don't remember if the 3rd Application.CreateForm get its' 'A' clipped or not, the other I'm sure are doubled and the IF gets its' "I" clipped).
Chasing on QualityCentral doesn't help (found nothing). This also happens sometimes on Class Completion(Ctrl-SHift-C).
Someone knows what triggers that bug, so I can create an new application and send it to Embarcadero?
Behavior like that suggests that the IDE is miscounting characters in the file. There are several "file oddities" that the developers might not have anticipated and that could cause a character index to be miscalculated.
Check your file for unusual line endings. For example, a line missing a carriage return will appear correctly in the editor, but can cause incorrect line numbers elsewhere in the program.
Non-breaking spaces are another kind of character that will appear normally, and maybe even parse correctly, but occupies multiple bytes when represented in UTF-8 when the "normal" version of the character (a regular space) only takes up one. You will sometimes acquire such characters if you copy code from a Web browser.
Incorrect byte-order marks for UTF-8 or UTF-16 source files might also cause problems.
Often, opening your source file in Notepad or a hex editor will help you identify these problems.

Delphi XE - All blue dots are shifted with one line up

Since yesterday, all blue dots (compiled lines) in my source code are shifted with one line up.
So, the first dot starts at 'var' instead of 'begin' and the last dot is one line before the last 'end' of a function.
I deleted all files (starting with DCUs) except DPR, PAS, DFM and DPRJ and recompiled. But the dots are still shifted.
How can I fix this? It makes the step=by-step debugging almost impossible.
It could be that the file is corrupted so that you don't have proper line end combination (#13#10) on one line. Is the "one line up error" throughout the file or does it start somewhere in the middle of the unit?
Beginning with Delphi 2007 (maybe already Delphi 2005) you can check the line ends in your code by enableing checkbox Show line breaks in Tools - Options - Editor options - Source options. The line breaks look like this:
As you can see, a CR on its own is not considered a line break and messes up the synchronization of the executable line dots
Try closing Delphi then deleting all *.identcache files.
I have a batch file at the root of my Delphi projects directory that recursively deletes all identcache files.
Try This:
Open the unit in an editor with capabilities to change codification, like Notepad++.
Code/save the file as ANSI.
Open or recharge the file in the Delphi IDE.
The dots must be in the right place.

Latex \tableofcontents command always shows blank Contents on first build

When I generate a .pdf file from a .tex file using pdflatex, only the "Contents" title is shown with no actual TOC. If I run pdflatex my.tex once more, it generates the TOC just fine. I can reproduce this simply by removing the .toc file. What I think is happening is that my .toc file is being generated too late -- so how can I make the TOC work first time? Should I be generating the TOC beforehand without using pdflatex?
This is normal. LaTeX document need several compilations to reach a stable state. Use rubber -d my to compile the right number of times (rubber comes as a package on many linux distros).
I might be mistaken, but I think, that this is the default behaviour. I assume, you also won't find correct cross references (footnotes, end notes, literature) after the first run of pdflatex.
The point is, that LaTeX needs the extra rounds to resolve the references pointing inside the document, to get numbering and page numbers right.
I experienced the same problem with the editor Latexian. What solved the problem was changing the preferences. I changed "Number of typesetter runs at end" to 3, instead of the default 1. Then I added the "Refresh" button to the toolbar and tried refreshing and it worked.

Resources