Is the relationship from a Slide Part to a Custom XML Part not an explicit relationship instead of an implicit? - vsto

If I want to associate a Custom XML Part to a Slide Part, the way I know of, is to add a custData element inside the Slide Part, and reference the relationship id of the Custom XML Part in the id attribute.
<p:custDataLst>
<p:custData r:id="rId1" />
</p:custDataLst>
As I understand it, this is an explicit relationship, because the reference is via the relationship id.
However, ECMA-376 Part 1, fifth edition (Latest version currently), says that a Slide Part is only permitted to have an implicit relationship to a Custom XML Part (Section 13.3.8).
That doesn't really make sense to me. In practice, I see an explicit relationship, while the specification only allows for an implicit one.
This is also how PowerPoint do it if I use the VSTO object model. If I create a completely fresh VSTO project, and edit the startup method to be like this:
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
Application.AfterNewPresentation += pres =>
{
var firstSlide = pres.Slides[1];
var customXmlPart = firstSlide.CustomerData.Add();
customXmlPart.LoadXML("<test></test>");
};
}
Then save the presentation and look at the package structure, PowerPoint did the exact same thing: Added a custData element to the slide, referencing the custom XML part using the relationship id. I.e. an explicit relationship.
I'm confident that the specification is correct, so what am I missing?

Okay, so it turns out that Office knowingly doesn't follow the specification to the letter. Luckily, Microsoft actually documents where they diverge from the standard. This documentation can be found at the Open Specifications website on MSDN. Diving into the documentation here, I found the page Word, Excel, and PowerPoint Standards Support, which has quite a few PDF documents that documents how the standard is implemented in Word, PowerPoint and Excel. Diving further into [MS-OE376]: Office Implementation Information for ECMA-376 Standards Support, section 2.1.23.e states:
The standard states that the Presentation part is permitted to have an implicit relationship to a Custom XML Data Storage part.
Office also allows for an explicit relationship between the Presentation part and a Custom XML Data Storage part.
The PDF document doesn't say anything about this for slides, but now I'm no longer unsure if I was interpreting the standard incorrectly or if PowerPoint just didn't follow the standard. It's pretty clear that PowerPoint in a lot of cases doesn't follow the standard, so the specific case I have with an explicit relationship between a Slide Part and a Custom XML Data Storage Part is probably just another case where PowerPoint doesn't follow the standard.

Related

how to apply digital signature on all pages of pdf using PDFBox library [duplicate]

I want to place same externally signed signature container (signature value) at multiple places in a PDF.
I have referred the page 'How to place the Same Digital signatures to Multiple places in PDF using itextsharp.net'.
While working with the above mentioned work-around, I observed that whenever I tried to place multiple signatures on single page like 4-5 times, it never worked. Always shows only one valid signature field and other fields as unsigned (unsigned PDF form fields). So couldn't understand the problem.
Now I wanted to know whether any reference material is available to see how PdfLiteral and PdfIndirectReference works? I have gone through the itextsharp reference document but couldn't get enough information. In addition to this is there any limitation on how many annotations/signature fields one can add in a PDF?
And If I have to use BlankSignatureContainer and MakeSignature.SignDeferred then how the signature will get attached to all the fields because in,
MakeSignature.SignDeferred(pdfreader, "Sig", output, externalcontainer)
we have to pass only one signature field name.
Thank you.
You are asking for something of which mkl wrote:
Beware: While this procedure creates something which does not violate
the letter of the PDF specifications (which only forbid the cases
where the same field object is referenced from multiple pages, be it
via the same or via distinct widgets), it clearly does violate its
intent, its spirit. Thus, this procedure might also become forbidden as part of a Corrigenda document for the specification.
Actually, what you are asking does violate the specification. See section 12.7.5.5 of the ISO standard for PDF:
Allow me to repeat the last line of this screen shot:
signature fields shall never refer to more than one annotation.
There is a shall in this sentence, not a should. A should isn't normative. It means that you should or shouldn't do something, but that you are not in violation with the spec if don't or do. Not respecting results in a PDF document that is in violation with the PDF specification, and that in the strict sense isn't a real PDF file.
That is a path you don't want to go, because being in violation with the PDF specification voids your right to use a series of PDF patents owned by Adobe. Adobe owns patents that can be used by everyone for free (perpetual, non-exclusive, royalty-free,...) on condition that you respect the ISO specification.
For that reason, please do not expect an answer to your question, except for the recommendation to abandon your requirement. PDF viewers that comply with the PDF specification won't expect a single signature to be placed at different locations because that's not allowed by the spec, so even if you would adapt your software to create more than one widget annotation / appearance for a single signature field, there is no guarantee that a PDF viewer will understand what you're trying to do.

What is a story?

In MS Word VBA, what is the unit of measure "Story" and where does it fit into the hierarchy of units in a Word document?
This reference only says that wdUnits.wdStory refers to "a story" which is not helpful. I couldn't find any other references that explain what I'm looking for.
This is actually a more complicated question than most would think. In a Microsoft Word blog post stories are defined as:
"...distinct regions of content that make up a Word document and share properties and functionality. Put differently, behind the scenes, Word breaks all documents up into a collection of chunks with shared properties and functionality. Officially, these are called stories."
These chunks can be comments, endnotes, footnotes, footers, headers, etc.
Later on the blog post states:
"...all stories in a document utilize a common set of properties that determine the presentation of the contents within each story. These shared properties include font information, style definitions, numbering definitions, and document settings."
For more information, please see the full Microsoft blog post:
Behind the Curtain: Stories in Word
UPDATE
#WaiHaLee has brought to my attention that the Microsoft blog post I link to in my original answer is no longer available. Because of this, I will elaborate further on what a Story is in the Word Object Model.
As of this writing there are 17 types of Stories, as this screen capture from the Object Browser of the Word VBA IDE shows:
Each of these allows a specific region of content within a Word document to be affected programmatically, often via the StoryRanges collection.
Allen Wyatt has written a very good article entitled
Including Headers and Footers when Selecting All
wherein he explains some different methods for using StoryRanges. For example, one can update fields in only the Primary Footer area of a document:
ActiveDocument.StoryRanges(wdPrimaryFooterStory).Fields.Update
StoryRanges can also be used to search particular areas of a document as detailed in
Using a macro to replace text where ever it appears in a document
So in short, the StoryRanges collection allows a programmer to affect all or some of the unique parts of a Word Document. Each part is a Range enumerated as a StoryType. And each StoryType is what is meant as a Story within Word.

Add VBA Project to Visio Document by Using Code

I've been asked to create a macro to update a few hundred or so Visio drawings, and keep them updated.
The update involves putting all objects of a certain type on their own layer - simple.
Now, this is easy enough to do, but when a user adds a new object some time in the future it will likely be on a default layer. So I had hoped to be able to include a VBA macro which is triggered by the Save event to re-assign objects to their layers.
The problem here is that I'd need to include this macro in every document since Visio doesn't have an application level VBA project.
Is there any way to introduce a VBA project to ALL Visio documents using code (VBA or otherwise)?? Or is there an alternative I might not have considered? Unfortunately an Add-in is not really an option due to available resources.
You have a couple options here:
Force every user to allow programmatic access to the VBA project for their documents, and use VBA automation to add code. This works nicely when you have programmatic access, but this can be difficult to assure.
If you're not using Visio 2013, you can actually save a document as VDX (xml) and replace the data for the VBA project with your own (you'd save out a document as VDX manually, and copy out the chunk of data for the VBA project). As I said, this wouldn't work with Visio 2013 since they seem to have eliminated the VDX format. You probably can get away with something similar with the VSDX XML format for 2013.
You can 'migrate' everyone's documents to a new VST file you provide. This would just involve copying and pasting all the content from a document into the new document that has your code in it. You have to be careful though to make sure all the document- and page-level data comes along, too (meaning DocumentSheet and PageSheet and any Document XML properties that may be important, and attributes like Author, Description, etc...)
Item 1 is the easiest, aside from the pain getting programmatic access to VBA Projects, unless you can have people send you documents to migrate.

How to Implement org.eclipse.wst.sse.ui.semanticHighlighting

I'm trying to implement content-assist and some custom highlighting as a plugin for Eclipse, after a lot of research I found this eclipse document.
I got content-assist working for XML documents, the problem is the part about SemanticHighlighting, I didn't find any information about how to implement this extension-point and I'm a bit lost. The only info that I found is the XSD for the extension point.
I'm trying to make some customs expressions on XML get a different color Ex:
<span>%%colored_text%%</span>
Where can I get more information about this org.eclipse.wst.sse.ui.semanticHighlighting and how to implement it?
I don't think there's a lot of a documentation on the semantic highlighting for SSE. The document that you found is a little light on details. For an example, the XSL project implemented semantic highlighting using the extension point.
The basic idea behind the semantic highlighting extension point is that when a change occurs, implementors will be asked if it can 'consume' a region of the document. If it can, it will return an array of Positions that can be highlighted by that particular highlighter. It can apply only one style, so it ends up being very specific. For example, you wouldn't be able to say 'color this part of the region blue and this other part of the region red'. You would need two separate highlighters to accomplish that.
The highlighter obtains style information for the highlight by using a preference store that you return from getPreferenceStore(). You'll then need to set up keys that the highlighter will use to look up styles from that preference store. If you use the styleStringKey on the extension point, the only key of importance from the semantic highlighting implementation is the one returned from getEnabledPreferenceKey(). This is kind of the condensed way to declare a style, as it only takes 2 preferences to get going. The semantic highlighting framework knows how the parse the string value returned by the preference store for the styleStringKey into the appropriate style components. Just follow the format as defined on the New Help for Old Friends document that you linked to.
Now, if you want to keep all the style components separate, the other get*PreferenceKey() methods become important. You'll have to define keys for each of them, and then add default values for each of those keys in your preference initializer.
org.eclipse.wst.xsl.ui.internal.preferences.XSLUIPreferenceInitializer has examples of both ways to define these style defaults.

How to import Microsoft Office constants (msoTrue, ppLayoutText...) into LotusScript?

I am trying to programmatically make a PowerPoint presentation from the contents of a Lotus Notes document. This is relatively straight-forward using CreateObject("Powerpoint.Application") but I fail to find a way to access the various constants that are used in VBA.
One solution is of course to hard-code the (ten or so) values into my script, but for obvious reasons I'm a bit uneasy about that solution.
Is there a way to lookup the value of for example msoTrue or ppLayoutText with LotusScript? For example a way to query the Powerpoint.Application object for the values?
(In more compentet languages adding various Interop libraries seems to do the trick, but I haven't found a way to do that in LotusScript.)
Edit
I prefer a solution that will work without any extra installation of software or dlls, apart from Office.
You can have your code lookup these MS constants by creating an OLE object of type "TLI.TLIApplication" object (defined in tlbinf32.dll), and then querying that object for all of the office VBA constants. There is an MSDN article describing this technique in general here:
http://msdn.microsoft.com/en-us/magazine/bb985086.aspx
There is also sample code for exactly this procedure in a LotusScript environment here:
http://noteslog.com/post/ole-constants/
Note that this is a runtime-only technique. This inspection method will make all of the constants available to your code, but will not make the constants available through Intellisense in the Domino script editor.
This is what I use for MS Office constants: Microsoft Constants Database. There is a script library that has recently been added for Word and Excel.