Issue 125187 - PPT-import: Some rare cases with missing graphic
Summary: PPT-import: Some rare cases with missing graphic
Alias: None
Product: Impress
Classification: Application
Component: open-import (show other issues)
Version: 4.2.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.2.0
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2014-07-01 09:20 UTC by Armin Le Grand
Modified: 2017-05-20 10:35 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2014-07-01 09:20:45 UTC
There are cases of ppt files (binary import) where the first big graphic is missing. This happens by simply opening/importing the file, the 1st pic on the 1st page shows the symbol for missing graphic (icon and name in red).
I have ppt example files where this happens, but cannot add as bugdoc due to the submitter not wanting that because of confidential content. Reducing or changing that file removes the error (using ppt 2003/2010), so no way yet to add a bugdoc.
Comment 1 Armin Le Grand 2014-07-01 09:25:02 UTC
Grepping and investigating. Problem is in filter module in SvxMSDffManager::GetDrawingGroupContainerData where the BLIP data is prepared. A BLIP can be directly embedded in the current partial stream read following the PLIP info which is processed or be in an own partial stream and an offset is read and remembered. The cirteria for the 2nd is that there is no BLIPPos read and no BLIPLen. This is in the submitted case not sufficient, the 1st pic later missing has 0 == BLIPPos, but is *not* embedded following in the local stream.
Comment 2 Armin Le Grand 2014-07-01 09:31:20 UTC
I have checked a dozen ppt files (bugdocs I have locally) which use the local embeddig (case A) and as content of another partial stream (case B). Except the bugdoc I have all of these work reliably with the condition (!nBLIPPos && nBLIPLen < nLenFBSE). Started to investigate further - until now seeked over - information in the context of reading BLIP info. The four bytes between reading nBLIPLen and nBLIPPos which are ignored until now contain a flag value which seems to flag that two cases reliably. This works reliably with my test files using both cases and the given bugdoc.
Adding code that makes use of this extra info loads all cases as intended. I cannot exclude that there will be deviating other cases, but using the proposed changes loads all ppt's I have checked reliably for cases A and B.
Checking more ppt files...
Comment 3 Armin Le Grand 2014-07-01 11:53:21 UTC
Done more and deeper checks with another bunch of ppt bugdocs (and from the net), all works as expected. I will add an extensive description to the sources, for the case other stuff comes up.
Still found no way to reduce the orig bugdoc, thus cannot add one. Thus this task will b reviewable only by checking that other random ppt imports still import all graphics and some also the first one now. Sorry for not having a publicly available bugdoc.
Preparing commit...
Comment 4 SVN Robot 2014-07-01 11:55:03 UTC
"alg" committed SVN revision 1607057 into trunk:
i125187 more precision at ppt import where the BLIP graphic is located
Comment 5 Armin Le Grand 2014-07-01 11:55:55 UTC
Okay, done.
Comment 6 slacka 2014-09-01 02:01:28 UTC
Could you please put a test doc so that the QA team can watch for regressions, especially after Issue 125476 is fixed. If it is a space issue, you can put a doc on a free site like:

Comment 7 Armin Le Grand 2014-09-03 09:27:24 UTC
Hi Slacka,
sorry, as written in the original comment and comment 3 the submitter of the original bugdoc did not want it to get public. I see your problem, but I have to respect that. As you can see I already tried to find other docs (comment 3) which could be used as bugdoc, but had no luck. No solution here currently.
Comment 8 slacka 2014-09-03 19:32:24 UTC

OK that makes sense. Would it be possible for you to supply a similar, censored,  or blanked out version of the image file that triggers the bug? I could then try various methods with PowerPoint and older versions of Apache to trigger the bug.