I read the a.pdf in Itext 5 and it is good. But the same pdf is read in Itext 7. I have next error, when I use PdfSigner:
Exception in thread "main" com.itextpdf.io.IOException: Error at file pointer 7,907.
Related
I've got a crash report for my macOS app. The crash is related to Realm and schema version.
But it also states the exact file/line of the crash, along with the full path to it (including my name):
Application Specific Information: Fatal error: 'try!' expression
unexpectedly raised an error: Error Domain=io.realm Code=1 "Provided
schema version 0 is less than last set version 4."
UserInfo={NSLocalizedDescription=Provided schema version 0 is less
than last set version 4., Error Code=1}: file
/Users/myNameHere/workspace/myProg/myApp/myVC/Utils/myFile.swift, line
40
It's the first time I see the full path, including my username at a crash report. I don't want this path to be printed. Can I change it somehow?
I face the following problem till trying to make export of .car file via wso2-devstudion from composite application project. The this is the error from the error log:
"!MESSAGE An error occured while creating the carbon archive file
!STACK 0
org.apache.axiom.om.OMException: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 middle byte 0xce (at char #822, byte #37)"
So the problem was with using of not Latin characters in one of the proxy services "envelope requests". Under Windows 7 (x64).
Solution of this problem is to add the following line in the Eclipse.ini file of your wso2-devstudio IDE:
-Dfile.encoding=UTF8
After that you should restart the IDE and problem is gone.
hi XCode 5 failed to compile file in 32-bit due to the size of the object file.
I tried to add -Bigobj flag but it doe not change anything.
I tried to change optimization settings without success.
the error is : "fatal error: error in backend: Section too large, can't encode r_address (0x1001a97) into 24 bits of scattered relocation entry."
There is no problems when compiling in 64-bit.
Does anyone have an idea about it ?
Thanks
Im trying to use the Windows API in Haxe to create a Windows application. I have already done this using ndlls and Haxe/Neko.
I tried doing it with the cpp target where I embed C++ code into the Haxe file using the new macro features in Haxe 2.09. But, as soon as I include windows.h it gives an error
./src/Main.cpp(79) : error C2039: 'RegisterClassA' : is not a member of 'hx'
./src/Main.cpp(81) : error C2660: 'RegisterClassA' : function does not take 9 arguments
Called from ? line 1
Called from BuildTool.hx line 1246
Called from BuildTool.hx line 554
Called from BuildTool.hx line 591
Called from BuildTool.hx line 710
Called from BuildTool.hx line 785
Uncaught exception - Error in building thread
Error : Build failed
Build halted with errors (haxe.exe).
Here is my code -
import cpp.Lib;
#:headerCode("#include <windows.h>")// if i comment this line or replace windows.h with another standard header file like iostream, the error goes
class Main
{
static function main()
{
//no code here
}
}
In fact, if I replace windows.h with any header file from the Windows or DirectX SDK, I get the same error
Im using Haxe 2.09 and FlashDevelop. I use Windows 7. I am also using the latest version of hxcpp (version 2.09).
Looks like <windows.h> is #defining RegisterClass to RegisterClassA (part of the auto-magic Unicode support).
Because this is done with a text-prepropcessor macro, any code that has a symbol named RegisterClass (as seems to be the case with BuildTool) has it automatically swapped out for RegisterClassA, which obviously causes problems if somebody goes looking for the function under its proper name.
Try this:
#:headerCode("#include <windows.h>")
#:headerCode("#undef RegisterClass")
You may need to do something similar for other clashes. See also this question.
I have to display a logo in every page of a generated PDF. Though it works fine in the local system, it throws following exception in the server:
Fatal error: Uncaught exception 'PDFlibException' with message 'Handle parameter or option of type 'image' has bad value 0' in /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/pdflib_adapter.cls.php:664 Stack trace: #0 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/pdflib_adapter.cls.php(664): PDFlib->fit_image(0, 30, 746, 'boxsize={86 43}...') #1 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/php_evaluator.cls.php(66) : eval()'d code(16): PDFLib_Adapter->image('http://rfqms.de...', 'jpg', 30, 3, 86.4, 43.2) #2 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/php_evaluator.cls.php(66): eval() #3 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/php_evaluator.cls.php(70): PHP_Evaluator->evaluate('??//$base_img_u...') #4 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/renderer.cls.php(180): PHP_Evaluator->render(O in /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/pdflib_adapter.cls.php on line 664
After some analysis I found that in local it uses cpdf_adapter.cls.php for image, where as in server it uses pdflib_adapter.cls.php for image.
I even tried for all the types of images according to:
pdfLib tutorial Version 8.0.2 ---page # 166--- Inline images are only supported for imagetype=ccitt, jpeg, and raw. For other image types the inline option will silently be ignored.
So, what is the problem that leads to this exception?
some additional info:
local PHP Version 5.3.0
server PHP Version 5.2.16
dompdf version 0.5.2
DOMPDF_TEMP_DIR has r/w/e permission
local machine is windows vista
server machine is linux
There was a bug in dompdf at some point related to adding images via PDFLib. I'm not sure if the issue has been addressed yet or not for the upcoming 0.6.0 release. There is a relevant thread on the support group. Take a look at my last post there for information on a work-around if you want to continue using PDFLib.
The other option would be to tell dompdf to use CPDF. In dompdf_config.inc.php set DOMPDF_PDF_BACKEND to "CPDF" instead of "auto" or "PDFLib".