How can I make InDesign render a region of a page, as it would be rendered when exporting the whole file?
I know I can render a PageItem using the exportFile function, but this will ignore any other PageItems sharing the same region.
My current solution is to make a new document the size of the region of interest, with a copy of each PageItem whose coordinates fall into that region. It’s very inelegant, and it seems it cannot be done without the user seeing windows meaningless to them come and go.
Another approach I can think of is to export the whole spread containing the region, then crop the resulting file using something like ImageMagick. But I’d still prefer to be able to render only the region I need, if possible.
You can open the InDesing document without showing its UI as well.
app.open(filepath, false);
and while closing the doc, simple use
doc.close(SaveOptions.NO);
You anyways don't need to save that doc on disk.
This will let you have the document open without showing its UI at all.
I did something like this recently. Here are my steps:
duplicate all spread items and group them
make a frame with a proper size/position
cut and paste the group into this frame
export the frame as PNG
If you need another region on this spread you don't need to repeat all the steps, you can change size and position of the frame and to export it again.
There is a limitation: master page items will be omitted.
Related
This question already has answers here:
Limiting file types for a specific DocumentChooserBlock() Block in Wagtail Steamfield
(2 answers)
Closed 1 year ago.
I'm writing a custom StreamBlock that is designed to render a table based on the data in a given CSV file. The CSV files will be stored in the usual Document store, so the block needs to present the Document chooser to let the user pick a CSV file.
I would like to restrict this block's Document chooser to documents whose filenames end in .csv, without affecting any other Document chooser. I dug into the code to try to figure out a way to do that, but after 30 minutes of poking around, it doesn't look like there's any obvious way to determine the source of a request to the admin/documents/chooser/ view, which is what actually renders the Document listing.
My best guess at the moment for how to do this would be to subclass DocumentChooserBlock and AdminDocumentChooser, so that I can tell it to use a custom version of wagtaildocs/js/document-chooser-modal.js. I'd change it to send an extra GET argument, or something like that, whenever CSVTableBlock's Document chooser sends a request to admin/documents/chooser/. Then I could implement construct_document_chooser_queryset to look for that custom GET arg, so it knows when to filter the documents queryset to only .csv files.
But I'm really not at all sure that this is the right way to go about it, or if it's even possible for that strategy to work. Is there a better/possible way to do this?
you actually no need to do anything, almost all use cases for such filtering scenarios, an editor can input the ".csv" in the search box of the chooser modal
I want to set up data driven subscriptions to mass output png files. The problem is that adding a new Extension for png in rsreportserver.config under Configurations/Extensions/Render only gives one fixed size of png file.
Report A really ought to output a 6in x 3in png file and report B ought to output a 6in x 4in png file.
Yes, I could create multiple entries in rsreportserver.config but this is confusing for end users as they show up on all users' export dropdowns needlessly.
I proposed doing the mass image generation with an external program that generates a custom url for each png (DeviceInfo settings can be part of the url) and uses WebClient.DownloadFile() in a loop, but my supervisor is currently really locked into the idea of data driven subscriptions for whatever reason.
Per #iamdave's suggestion, just setting the overarching page dimensions in report designer does give a suitably sized png file via data driven subscription without having to hardcode png dimensions in rsreportserver.config.
The reason I didn't initially notice this was the reports in question were graphs that were only ever used as subreports on an encompassing megareport and had never really been run as individual standalone reports. When used as a subreport, page dimensions never came into play, so they were left at the default 8.5x11.
How to get to $(document) in the onReady method ?
I've tried with smoothState.cache[smoothState.href] but couldn't make it works.
(fantastic plugin)
Thanks
I'm assuming you want to get at the document for the new page that's being loaded. Technically, $(document) exists in onReady, and it's the first document you visited on the site. After that, smoothState just dynamically updates it by swapping out content. So whatever existed on the previous page you were viewing is there as normal. Once the line $container.html( $newContent ); runs in your onReady method (assuming your code follows all the smoothState examples), you new content should be available.
However, if you want to get at the actual, full document for the new page that got loaded up, not just what's contained in your wrapper div that gets swapped out, it's contained in smoothState.cache[smoothState.href].doc. It's got the header, the body, everything.
A little reading of the smoothState source code shows that you can pull it into a useful format this way:
var $newDoc = $("<html></html>").append( $(smoothState.cache[smoothState.href].doc) );
At this point, you can run find queries or whatever you need to go look through things.
I have a custom list renderer that has a logo for a business in it. It has a label Logo_URLImage that has the placeholder image. In my code I get the data and assign HashMaps to the list model, h.put("Logo_URLImage",imageURL); where imageURL is a string that has the absolute URL to the image.
On Android it seems to always work, but most of the testing has been on iOS devices. What happens is that images are updated as you'd expect the first time or two that you run it. A run later on will show blank images (flash the place holder image and then blank) and once that happens images will never come back.
Any thoughts on what might be causing this?
Check that you defined the LogoName map entry. Check that it is unique per image?
Check that it doesn't include special characters that might cause an issue.
I am trying to figure out how to make a hyperlink in a Livecycle Form which points to a URL which will change on different days that the form is rendered. For example on one day I might want the hyperlink to point to:
mywebsite/mypage?option=XXX
and on another day I want it to point to:
mywebsite/mypage?option=YYY
The XXX and YYY can be passed into the form's data pretty easily as XML, but I just don't know how to make it so that the hyperlink is changed to correspond to this.
Any suggestions?
This can be accomplished with JavaScript in LiveCycle Designer. The following script, placed on the Form's docReady event will let you dynamically change the URL of a text object.
form1::docReady - (JavaScript, client)
// If this code is running on the server, you don't want it to run any code
// that might force a relayout, or you could get stuck in an infinite loop
if (xfa.host.name != "XFAPresentationAgent") {
// You would load the URL that you want into this variable, based on
// whatever XML data is being passed into your form
var sURL = "www.stackoverflow.com"; // mywebsite/mypage?option=xxx
// URLs are encoded in XHTML. In order to change the URL, you need
// to create the right XHTML string and push it into the Text object's
// <value> node. This is a super simple XHTML shell for this purpose.
// You could add all sorts of markup to make your hyperlink look pretty
var sRichText = "<body><p>Foo</p></body>";
// Assuming you have a text object called "Text1" on the form, this
// call will push the rich text into the node. Note that this call
// will force a re-layout of the form
this.resolveNode("Text1").value.exData.loadXML(sRichText, false, true);
}
There are a couple of caveats: URLs in Acrobat are only supported in Acrobat 9.0 and later. So if someone using an older version of Acrobat opens your form, the URLs won't work.
Also, as you can see from the "if (xfa.host.name !=...)" line, this code won't run properly if the form is being generated on the server, because forcing a re-layout of a form during docReady can cause problems on certain older versions of the LiveCycle server. If you do need to run this script on the server, you should probably pick a different event then form::docReady.
I a number of complaints from users in WorkSpace that clicking links opened them in the same tab so they lost their WorkSpace form, and there's no option to change that in Designer 11. I think the solution I came up with for that would work for you too.
I made buttons with no border and no background, and in their click event have this line (in Javascript, run at client)
app.launchURL("http:/stackoverflow.com/", true);
It would be easy to add some logic to choose the right URL based on the day and it doesn't cause any form re-rendering.
In some spots where the hyperlink is in line with other text, I leave the text of the link blue and underlined but with no hyperlink, and just place the button (no background, no border, no caption) over it. Does require positioned and not flowed subforms for that to work, so depending on your layout it could get a little clunky.
Wow, just realized I am super late to the party. Well, for anyone using ES4 facing a similar problem . . .
Ended up using a 3rd party component to manipulate the PDF's hyperlinks...wish there was a better solution as this one costs about $1000.