ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

patrick.corless wrote:

The snippet would look like this.

Code:

Hashtable dictionary = font.getEntries();
         if (entries.containsKey("BaseFont")) {
             Object o = entries.get("BaseFont");
             if (o instanceof Name) {
                 basefont = ((Name) o).getName();
             }else if (o instanceof Name){
                 basefont = (String) o;
             }
         }

Thank you very much for this snippet.
It is quite possible that I (or, rather, my converter) can even live with the font name that your modification is going to deliver. Although, if it's strongly dependent on the system on which the converter is running, that would perhaps not be so great. In that case I would likely try to take advantage of the basename lookup that you have suggested.

patrick.corless wrote:

Just poked around the code a bit an there appears to be a bug in org.icepdf.core.pobjects.fonts.ofont.Font.java and FontDescriptor.java which is responsible for the "fontName" value.

The value will effect font substitution in a small percentage of files. The good news is that the fix is very easy. http://jira.icefaces.org/browse/PDF-204

Can you give more information on how you plan to use the font name? Do you want the font name as specified in the PDF or do you want the name of the font used to render the content?

Thank you for your reply!

I use the font name to generate XAML from the PDF. XAML does the font rendering all by itself. All I need to tell it is where the font file happens to be (I can do that if I get the right font name). This works for many of the PDF files that I want to convert (I have already converted hundreds of PDF documents this way: those are documents of a database of math exercises with worked solutions - where each exercise / solution is a separate document). Especially it works with PDFs that I have created with the help of pdftex and pdflatex (tools of the TeX family) and the public fonts that are distributed along with TeX. It does not always seem to work with PDFs that refer to certain fonts, like Times, and/or (possibly) PDFs that have not been generated by pdftex/pdflatex.
I certainly would like to get the font name as defined in the PDF, since, as I wrote, my program does not have to bother about rendering fonts at all. Admittedly, my application is rather special. Therefore, I certainly would not recommend that you modify the behavior of ICEpdf in a direction that suits my PDF to XAML converter, but with which you do not feel comfortable yourself.

Thanks,
Christian

ICEpdf-core 4.1.0 cannot determine the font name (Times-Roman) of the font contained in the attached PDF correctly. Instead of the correct name, which is "Times-Roman", font.getName() gives me the nonsensical generic label "FontName".

Why is it, that ICEpdf cannot determine the real name of the font while Acrobat Reader, for example, can do it?

patrick.corless wrote:

I took another look at this and I can't seem to see the transparency issue with the image capture. Attached is my captured imaged and it looks the same as viewer image as I would expect to see.

PROBLEM IDENTIFIED: To simplify stepping through the source I had build ICEpdf from the sources. But those sources were of version 4.0.1, whereas the binary version of ICEpdf.core is version 4.1.0. If I change the image type to TYPE_INT_ARGB in a version of document.java that I compile against the 4.1.0 version of the library, then I too can make PageCapture render transparency correctly.

Well, that isn't too bad: I really prefer to compile against the binary version of ICEpdf.core. - I just like to step through the source in order to learn how things hang together. In particular, since I wanted to get the glyphs themselves, and not the outlines of glyphs, in order to generate compact XAML code, I had to understand why it was that my implementation of Graphics2D only got the outlines, not the glyphs: hence my wanting to step through the source.

Thank you very much for helping me figure out what the problem was,
Christian Stapfer

patrick.corless wrote:

I took another look at this and I can't seem to see the transparency issue with the image capture. Attached is my captured imaged and it looks the same as viewer image as I would expect to see.

You're right: your image looks perfectly ok. It looks great in fact! It does not, however, when I try that. So there must be something wrong with how I have set up the ICEpdf core library on my system, it seems. I will have to look into this.

If you want to take a closer look at what ICEpdf is painting put a break on the Shapes.paint(...) method. The instance var Vector<Object> shapes contains all the paint operations. In the sample PDF there are 135 paint operations. I can see the needed transforms and alpha values, maybe this will help you with the converter.

Thank you very much for the information. I have already stepped through some of that code and looked as those objects.
So the first thing for me to do is to get the PageCapture example to run correctly on my system as regards transparency, I think. When that works, I can go back to my PDF->XAML converter (which is already working great, except for transparency).

patrick.corless wrote:

Try the following code instead to get around this limitation:

Code:

...
 BufferedImage image = new BufferedImage(pageWidth,
             pageHeight,
             BufferedImage.TYPE_INT_ARGB);
 ...

Thank you very much for your reply!

That would seem like an obvious cause of the missing transparency: but unfortunately, this change, specifying image type TYPE_INT_ARGB, does not produce the hoped for change. The resulting image looks exactly as before (with image type TYPE_INT_RGB).
Also, this relates to the problem that I see with my own impemention of a subclass of Graphics2D for conversion to XAML. There, too, I don't seem to get the right alpha value (it is always either 0.0 or 1.0).

P.S: I think that I am just not handling the Composite component of the graphics context properly. I had assumed, naively, that the color would have its alpha value set as required. That doesn't explain the problem with PageCapture but it's likely the reason my PDF to XAML conversion does not set the transparency of a fill color as required.

P.P.S: I have stepped through my code with an eye to the handling of composites, but even though AlphaComposites are being parsed from the PDF file, my code never sees one that has an alpha other than 1.0. So my handling of composites does not seem to be the problem. The fill color of the three circles of my test file, pgf-test.pdf, really should have it's alpha set to a value <1.0, it seems to me.

There is a significant difference in how transparency is handled by the PageCapture example and your Viewer application.

The transparent colors in the attached PDF are handled correctly by your Viewer application, but are treated as solid, non-transparent colors by your PageCapture example.
Why is that? Is transparency generally not handled (correctly) by the free version of ICEpdf? I'm just asking for information: to avoid wasting any more time looking for a problem with my own code when it perhaps really is in the (open version) of the core library...

I am trying to use ICEpdf to convert PDFs to XAML. Maybe not with all features that one might want to use in a PDF: I need only glyphs and GeneralPaths.

I have implemented a subclass XamlGraphics2D of Graphics2D for this purpose, but have found that, although Graphics2D has an entry point drawGlyphVector(), that entry point is never called. Instead, glyphs are converted to paths (outlines) by OFont.drawEstring() and then rendered using Graphics2D.fill().
Not only would this require a font engine, in order to work in the general case, but, worse, it would blow up the size of the generated XAML too much (easily by a factor 10, or more).
So I boldly modified the code of OFont.drawEstring() to invoke Graphics2D.drawGlyphVector() instead of converting the glyph to outline and then invoke Graphics2D.fill() for this outline.
I think, by converting glyphs to outlines so early you are heading off some useful applications (certainly, for my purposes, conversion from PDF to relatively small XAML files is useful).

Of course, the question is how I manage to tell the XAML renderer what those glyphs look like. I have no solution that works generally (one would have to extract the font file and convert it to an odttf or just a ttf file for that), but because for my application (a shared whiteboard) all the relevant fonts can be assumed to be installed on the machine of someone who wants to render the generated XAML, I do not have to supply the font files at all, but can simply reference the installed font files instead.

I still have trouble converting GeneralPaths correctly. The problem seems to be that my implementation of Graphics2D does not get the transform right if a vector drawing is included somewhere in the PDF to be converted. But since your Viewer application does display those vector drawings exactly in the right places, it must be the fault of my (current) XamlGraphics2D implementation...