Thanks for pushing this. The newer hyperlink work in requirement sets (1.6 and now 1.10) is a step forward, but there is still a major gap that blocks real PowerPoint automation: creating internal slide-to-slide links.
Today we can set a hyperlink address and screen tip, which is fine for external URLs. What we cannot do is create the native PowerPoint “jump to slide” hyperlink that PowerPoint stores as ppaction://hlinksldjump and ties to a relationship for a slide target (the equivalent of SubAddress in COM/VBA). That missing capability prevents a lot of common scenarios:
- Building an automated table of contents or agenda where each entry jumps to the right slide
- Creating in-slide navigation bars (tabs) for long client reports
- Validating and repairing internal links after slides are inserted, deleted, or reordered
- Ensuring those internal links survive “Save As PDF” so the navigation works in the distributed PDF
Without internal targets, the workarounds are ugly: VBA-only tooling, VSTO/COM-only authoring, or worst of all, server-side Open XML rewriting of the PPTX package and re-uploading to SharePoint, which is risky during coauthoring because it can overwrite live edits and disrupt AutoSave.
Feature request: please extend PowerPoint hyperlinks to support internal targets in a first-class way, either:
- subAddress (read/write) similar to other Office hosts, or
- a dedicated API like setHyperlink({ targetSlideId: ... }) / linkToSlide(slideId) that is stable even when slide order changes.
That one addition would unlock ToC automation, nav bars, and reliable PDF navigation without forcing customers into unsafe file rewrite workflows.