Bug 46622 - [patch] support for swftools - updateFont()
Summary: [patch] support for swftools - updateFont()
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-25 10:41 UTC by gawain
Modified: 2012-03-11 15:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
add parameter "now" to updateFont() (1.39 KB, patch)
2012-02-25 10:41 UTC, gawain
Details | Splinter Review

Description gawain 2012-02-25 10:41:44 UTC
Created attachment 57635 [details] [review]
add parameter "now" to updateFont()

swftools has a tool to convert pdf to swf (Flash) files. To do this, it uses a
patched xpdf instance. For debian i try to port swftools to poppler, but
swftools needs some code, that is not available in poppler.

So please add the following patch to poppler. It adds a second parameter "now" to updateFont() that forces the immidate update of font configuration without need to call drawChar(). Alternatively it would be ok for me if needFontUpdate and doFontUpdate() are made public or a new public function gets added, that has this meaning.
Comment 1 Albert Astals Cid 2012-02-26 11:09:53 UTC
*******
Alternatively it would be ok for me if needFontUpdate
and doFontUpdate() are made public or a new public function gets added, that
has this meaning.
*******
There is no doFontUpdate() in poppler, i'm confused.
Comment 2 gawain 2012-03-01 13:24:17 UTC
Dammit, i always get it the wrong way... i'm talking about

void SplashOutputDev::doUpdateFont(GfxState *state);
Comment 3 Albert Astals Cid 2012-03-01 13:32:54 UTC
To be honest i don't see your use case, are you inheriting from SplashOutputDev?
Comment 4 gawain 2012-03-01 13:53:10 UTC
swftools implements an own class InfoOutputDev. That one is not derived from SplashOutputDev, but creates instances of it to render pdf to flash swf. It needs to retrieve the current splash font without actually drawing some text (with is currently required to get the font info updated). So it patches the (embedded) xpdf code to make doUpdateFont() public. Its an hack...
For porting swftools to poppler there must be a method to get the same functionality without hacking...

Some snipped of code from swftools:

void InfoOutputDev::updateFont(GfxState *state) 
{
    GfxFont*font = state->getFont();
    if(!font) {
        current_splash_font = 0;
        return;
    }
    if(font->getType() == fontType3) {
        current_splash_font = 0;
        return;
    }
    GfxState* state2 = state->copy();
    state2->setPath(0);
    state2->setCTM(1.0,0,0,1.0,0,0);
    splash->updateCTM(state2, 0,0,0,0,0,0);
    state2->setTextMat(1.0,0,0,1.0,0,0);
    state2->setFont(font, 1024.0);
    splash->doUpdateFont(state2);

    current_splash_font = splash->getCurrentFont();
    delete state2;
}
Comment 5 Albert Astals Cid 2012-03-01 14:31:52 UTC
To be honest i don't like any of the solutions (actually your first one is broken), moreover we don't recommend people using poppler internals as we change them as we see fit to make stuff better, so you requiring this change in the headers means we need to "keep" this API for you in the internal headers and we don't want to have anything tying us in the internal header.

You should really look into a way of doing this wihtout requiring any poppler code change. 

But as a compromise solution i can make doUpdateFont protected. Then you make a class yourself that inherits from SplashOutputDev and has a function that calls doUpdateFont.

But note that as said we will change this function if we need it.

Deal?
Comment 6 gawain 2012-03-09 23:39:11 UTC
Sorry, i was busy lately.

I would like to make this working in a way without poppler changes. But i have no idea how to do it. So yes, it would be fine, if you make it protected and i will try to solve my problems by my oen subclass.
Comment 7 Albert Astals Cid 2012-03-11 15:38:57 UTC
Function made protected


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.