A Dilluns, 18 de maig de 2009, Hal V. Engel va escriure: > On Monday 18 May 2009 03:33:09 am Leonard Rosenthol wrote: > > Or most likely, create the various intents on the fly and cache them. > > Recreating each time you encounter them will have performance penalties > > (since creation of a transform is fairly heavyweight). > > > > Leonard > > The current code creates a transform for each ICCBased object. From my > reading of the PDF spec. only ICCBased objects can have different intents. > Therefore it would not add any new overhead to create the transforms with > the correct intent other than the added overhead of getting the correct > intent from the dictionary. As Koji points out below there is some > complexity to figuring out what the intent should be for any given object's > transform. > > The current code does have some hooks for caching of transforms and has a > reference count on the transforms for this. But this is currently > unimplemented since there is no way to check to see if a given transform is > already available so that it can be reused. Implementing this could make > the code more efficient but it will be non-trivial. > > >On Behalf Of Koji Otani > > snip > > > hvengel> Looking at the PDF specification I see that it is possible for > > the the hvengel> dictionary for a Device* object to have a default color > > space specified. I hvengel> don't know if the altona document has this > > but looking at the code it is clear hvengel> that no attempt is made to > > get or use the default color space for the Device* hvengel> objects. If > > it is in the document it should be used any time the Device* hvengel> > > color space is not a match with the output device color space. hvengel> > > > > I see. Color management code which I added doesn't touch Device* color > > spaces. > > And this is likely to be non-trivial to add since the PDF specification is > not very clear about how this should be done. At this point I think the > focus should be on getting CM support in place for ICCBased and CIEBased > objects. In addition this needs to be extended so that it is exposed in the > various bindings like I did with the Qt4 bindings in the patch I created. > The current code along with the various patches has most of this working > (other than rendering intent and all of the bindings) although it could > stand to be tested by a wider audience. So it is mostly a matter of > cleaning things up and finding and removing bugs in that code to get to > that point. > > snip > > > hvengel> #36, #37 and #38 do not show any of the difference from changes > > to rendering hvengel> intent that should be there. > > hvengel> > > hvengel> Looking at the code it is always using > > INTENT_RELATIVE_COLORIMETRIC and there hvengel> is no attempt to get the > > Intent from the dictionary in > > hvengel> GfxICCBasedColorSpace::parse(). So the code is not parsing out > > the intent and hvengel> using that to create the transforms. I had a > > look at the code but I was not hvengel> able to get the Intent from the > > dictionary since I am not at all familiar with hvengel> the code base. > > Perhaps someone who understands how the dictionary stuff hvengel> works > > could take a look at adding this to GfxICCBasedColorSpace::parse(). > > hvengel> > > > > As Leonard said INTENT can come from several places, it's not so > > simple to handle INTENT correctly. We have to check if current INTENT > > is changed and recreate transform if needed. > > This is why I didn't support INTENT this time. > > And when I looked at how this might be implemented in the code I can > understand why this is the case since it will be fairly involved. I spent > about a half day looking at this and I still had no idea what needed to be > done. Of course someone who has a better understanding of how the > dictionary stuff works and also how to read the PDF specification might > have a easier time figuring it out. It is not going to be trivial to > implement but it is the only significant piece that is missing from having > correct handling of ICCBased objects.
Go Hal Go! You can do it ;-) Albert > > Hal > _______________________________________________ > poppler mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
