c# - ItextSharp font color issue in ver 5.5.4+ -
i have code creates red "stamp" using red font color:
string stampdate = datetime.now.tostring("mm/dd/yyyy"); string fontpath = server.mappath("/assets/fonts"); string origfile = server.mappath("/test.pdf"); const int opacitypercent = 80; const float pdfpaidfontsize = 28; const float pdfcopyx = 170; const float pdfpaidx = 385; const float pdfy = 20; const float pdfdatexoffset = 7; const float pdfdateyoffset = 12; const float pdfdatefontsize = 10; const string paidstamptxt = "paid"; const string copystamptxt = "copy"; const string arialfilename = "arialbd.ttf"; pdfstamper stamper = null; pdfreader reader = null; pdfreader.unethicalreading = true; memorystream streampdf; try { reader = new pdfreader(origfile); streampdf = new memorystream(); stamper = new pdfstamper(reader, streampdf); (int = 1; <= reader.numberofpages; i++) { pdfgstate gstate = new pdfgstate(); gstate.fillopacity = gstate.strokeopacity = opacitypercent / 100f; pdfcontentbyte overcontent = stamper.getovercontent(i); overcontent.savestate(); overcontent.setgstate(gstate); overcontent.setcolorfill(basecolor.red); overcontent.begintext(); basefont font = basefont.createfont(basefont.times_bold, basefont.cp1252, basefont.not_embedded); overcontent.setfontandsize(font, pdfpaidfontsize); overcontent.showtextaligned(pdfcontentbyte.align_left, copystamptxt, pdfcopyx, pdfy, 0); overcontent.showtextaligned(pdfcontentbyte.align_left, paidstamptxt, pdfpaidx, pdfy, 0); overcontent.setcolorfill(basecolor.black); font = basefont.createfont(path.combine(fontpath, arialfilename), basefont.cp1252, basefont.not_embedded); overcontent.setfontandsize(font, pdfdatefontsize); overcontent.showtextaligned(pdfcontentbyte.align_left, stampdate, pdfpaidx + pdfdatexoffset, pdfy - pdfdateyoffset, 0); overcontent.endtext(); overcontent.restorestate(); } } { if (stamper != null) { stamper.close(); } if (reader != null) { reader.close(); } } byte[] pdf = streampdf.toarray(); response.cache.setcacheability(httpcacheability.nocache); response.buffer = false; response.clear(); response.clearcontent(); response.clearheaders(); response.charset = string.empty; response.contenttype = "application/pdf"; response.addheader("content-length", pdf.length.tostring()); response.addheader("content-disposition", "inline;filename=test.pdf;"); response.binarywrite(pdf); response.close();
the resulting pdf text has gray color instead of red. when reverted ver 5.5.3 shows red again. have tried 5.5.4 , 5.5.5 , both appear have same issue.
my question is: bug or need change code newer?
edit: appears issue pdf files. changing fonts , pdf file versions did not seem have effect.
comparing pdf work , pdf not work (neither can share publicly) noticed pdf not work tagged pdf, has fast web view enabled, , produced adobe pdf library. pdf work not tagged pdf, not have fast web view enabled, , created itextsharp.
since cannot control source pdf files be, reverted earlier version of itextsharp seems work time.
a first attempt reproduce issue
i executed code these values:
int opacitypercent = 70; int pdfpaidfontsize = 20; string copystamptxt = "copy"; string paidstamptxt = "paid"; int pdfcopyx = 100; int pdfpaidx = 250; int pdfy = 500; string fontpath = @"c:\windows\fonts"; string arialfilename = "ariali.ttf"; int pdfdatefontsize = 30; string stampdate = "today"; int pdfdatexoffset = 0; int pdfdateyoffset = 35;
with simple source pdf, , result pdf looks this:
in contrast observation
the resulting pdf text has gray color instead of red.
the resulting text color reddish (a partially transparent red on white).
i tested using itextsharp 5.5.5.
to gray color instead of red, therefore, there must special variable values or source pdf, not general itextsharp issue.
reproducing issue using file provided op
after first attempt reproduce issue, op provided sample file test.pdf, , indeed, file result of same code is:
thus, there indeed issue.
analysis
a comparison of added content stream operations in both cases shows:
for first attempt using sample pdf:
/xi0 gs 1 0 0 rg bt /xi1 20 tf 1 0 0 1 100 500 tm (copy) tj
for second attempt using op's sample file:
/xi0 gs 1 0 0 rg bt 0 g /xi1 20 tf 1 0 0 1 100 500 tm (copy) tj
thus, in spite of same code been used, there additional 0 g
operation in latter case, , operations selects black fill color.
this came quite surprise. thus, looked through itext code , code history explanation (i chose itext/java code that's original development takes place , changes can inspected more thoroughly).
and indeed, pdfcontentbyte.begintext
ends with:
if (istagged()) { try { restorecolor(); } catch (ioexception ioe) { } }
backgrounds
thus, in case of tagged pdfs method "resets color". why that?
looking through code history gives hints
revision 5499 tagged pdf support: keeping graphics , text in 1 canvas. not yet ready...
revision 5515 now itext can write both text , graphics 1 canvas. should set pdfdocument.puttextandgraphicstogether true.
here block above first appears slight difference
if (autocontroltextblocks) { try { restorecolor(); } catch (ioexception ioe) { } }
i.e. here color restored if
autocontroltextblocks
true
....
revision 5533 writer.istagged property decides whether write content in 1 canvas or separate ones.
here flag
autocontroltextblocks
replacedistagged
call of associated writer.
my interpretation:
to support tagged pdfs, necessary or @ least advantageous keep graphics , text in 1 canvas (formerly created in different canvasses concatenated, related graphics , texts distant each other in content).
to keep graphics , text minimal overhead in highlevel code, new autocontroltextblocks mode has been added
pdfcontentbyte
starts , stops text objects automatically needed , saves , restores separate color set texts.this mode seems have been chosen means support of tagged content in itext while seems not have been considered useful other contexts. thus, mode automatically used tagged files.
in opinion choice not optimal. pdfcontentbyte
part of publicly available itext api , publicly advertised (as "over content") low-level tweaking of generated or pre-existing pdfs. introducing such side-effects violates api contract, @ least nuisance keeping people upgrading.
work-around
simply switch order of color setting , text object starting operations, using
... overcontent.begintext(); overcontent.setcolorfill(basecolor.red); ...
results in
resolution
if interpret final check-ins correctly, issue should fixed in itext version 5.5.6.
commit 301a45b57dcef37ae0ec3625fbdd6caaf4004a3a
removed deprecated logic of saving , restoring color tagged pdf documents in pdfcontentbyte class (dev-1371).
Comments
Post a Comment