Forum Replies Created
-
AuthorPosts
-
Theunis De Jong
MemberActually, I don't think any of your original queries selects e-mail addresses either. All of them presume a http, ftp, or www prefix, which is quite uncommon for an e-mail address to start with.
I don't think it's worth the trouble to attempt to match both web pages and e-mail addresses in one go. They are significantly different, as you've already noticed.
December 11, 2012 at 6:24 pm in reply to: GREP: Find X if followed by Y but not if Y is followed by Z? #63728Theunis De Jong
MemberStrangley enough, you can nest positive and negative lookaheads!
In steps: find All Caps with bu{2,}
followed by “[Ss]creen” (uppercase or lowercase 's'), we get
bu{2,}(?=s[Ss]creen)
(I'm assuming you want a space in between) but then not followed by “button”, which is (?!sbutton):
bu{2,}(?=s[Ss]creen(?!sbutton))
Note how the negative lookahead for “button” is inside the positive lookahead for “screen”. (The trick to insert in this editor is to insert them twice: \.)
Now for the bad news…
I would also like the Change to: format if someone knows.
Often asked, but unfortunately InDesign's GREP cannot automatically change uppercase to lowercase, or the reverse.
Theunis De Jong
MemberIf I suspect the contents are not going to be adjusted but page numbers might, I replace the generated page numbers with Cross References. Then it's just a case of keeping an eye on the occasional chapter title correction, because they will need to be repeated in the TOC as well.
Once I ventured into inserting the entire chapter title as 'cross references' in the TOC but that didn't lead to the expected result (“easier to maintain”) but rather the opposite.
December 6, 2012 at 4:07 pm in reply to: Is there a way to "convert" (or invert) a "western" document to a right-to-left Persian one? #63694Theunis De Jong
MemberI've never worked with the ME version, but I bet you can find something like “Page Binding Side” in Document Setup. The Scripting guide shows this value can be either “Bound on the left” or “Bound on the right”, which nicely corresponds to a book that is read front-to-back or … (oh wait) I mean right-to-left (what you are most likely used to) or left-to-right (for Hebrew, Arabic, and probably a couple of other scripts).
(Correction) Um, it depends on the wording :)
If you consider how the pages turn while reading, an English book is “right to left'. But on second thought, maybe this can be best described as in which direction you read: left to right for English, right to left for Farsi.
.. That “oh wait” is of course because books in Farsi are also read front-to-back. It's just that the front is on the other side, the back side (which is then, of course, the front side).
Theunis De Jong
MemberWell yeah, your script checks only the very first text frame. If you want to check *all* frames, you will have to use a loop:
var myDocItems = app.activeDocument.textFrames;
for (i=0; i<myDocItems.length; i++)
if(myDocItems[i].contents == “ABC”)
myDocItems[i].label = “123″;
Theunis De Jong
MemberI guess we need a bit more to go on, your code runs fine as is. If you need other labels for other contents, just keep repeating the last two lines.
Theunis De Jong
MemberIn fact it's the epub that is immature, instable, and ill-defined. You cannot rely on seeing your epub to appear the same, or even “rather” similar, on different viewers, and with different software.
That said :D the target usage for an epub is slightly different. An epub can freely reflow its text; with appropriate software, you can change the font size and the font itself. Since it's a plain text format, it's extremely easy to search for text (other than in any random PDF). You can zoom in on a PDF up but then you have to move a page around to read it in its entirety. E-pubs don't need that.
The biggest drawback of the e-pub format is that it's still very much in its infancy, and that its parameters are not very strictly defined. Thus you cannot depend on your text to appear the same on various devices, much as you could not rely on web pages displaying correctly back during the dark age of the Browser Wars.
Theunis De Jong
MemberYour image was a bit too small to recognize the problem, but this remark speaks volumes;
I'll get by by NOT using the Opentype fraction option ..
It seems you are applying this option to your entire text. Don't; just apply it to the numbers that are supposed to be formatted as fractions.
Theunis De Jong
MemberPage range:use “pageString”, which is a text string. It comes with this description:
The page(s) to export, specified as a page number or an array of page numbers. Note: Valid when PNG export range is not all.
so don't forget to set pngExportRange as well.
The description may seem confusing at first — it's defined to use a 'string' but the description calls it a 'page number'. This is because in InDesign, a page number is a text string, since a page can be 'numbered' “xviii”, or “Section 2:B”, or “001”.
See https://jongware.mit.edu/idcs6j…..rence.html for all available preferences and the value types they accept. (Quite surprisingly, “pngQuality” is among them as well. I was pretty sure 'quality' was a JPEG-only thing. I wonder if it actually makes any difference whether you use LOW or MAXIMUM quality.)
November 20, 2012 at 2:52 am in reply to: GREP inconsistency finding variable? Or am I holding it wrong? #63579Theunis De Jong
MemberThat's really interesting. I have some text such as “A:1″, where the number is a custom variable, and I can find it using
:~u
To find just the colon, I expected this to work:
: (?=~u)
It doesn't, so let's try the inverse: find a colon where there is no variable following!
: (?!~u)
This also matches nothing … and I'm totally sure one of these two ought to have found something!
InDesign's GREP is great (in general), but one of the most annoying featurettes is that it does not tell you why a particular search failed. A “bad” GREP expression gives the same result as a no-match-found: “Cannot find match”. But if a plain search finds nothing and the inverse (finding it “not”) also finds nothing, then you can be pretty sure ID just does not understand the expression.
Since lookahead does work correctly with other 'tilde' codes such as ~., I'm inclined to call out Bug, and you may very well report it to Adobe with a Bug Report.
Theunis De Jong
MemberJust for laffs, I just timed the above two scripts on a fully formatted 200 pages long scientific thesis. FindText-then-check took 1399 milliseconds, the same thing took everyItem 553 ms; both changed the same 61 occurrences.
Theunis De Jong
Member“Find one by one” is actually a good way — of course, it depends on how you do that! The findText command is very reliable for these kind of operations, as it returns a complete list of all occurrences of your character style. The only caveat emptor is that the returned list of occurrences is a static copy; that is, if you change something in the text of the first found item, the references to all next occurrences will be off. The common solution is to work backwards through your found list of items (and findText can return the found list in reverse, so you don't even have to run 'backwards').
This is only necessary when you are doing something with the actual text, such as inserting or deleting characters, or adding a hyperlink, XML, anchored object or index marker — these all insert invisible codes into text. It's not necessary when changing formatting, such as adding underline or changing the font.
Here is a sample script that adds underline to all occurrences of a character style (just as a visible example; this could be done better by changing the character style definition!).
app.findTextPreferences = null;
app.findTextPreferences.appliedCharacterStyle = “Emphasis”;
result = app.activeDocument.findText(true);
for (i=0; i<result.length; i++)
{
result[i].underline = true;
}If speed is of the essence, you could venture into the realm of Advanced Scripting. One of InDesign's most powerful scripting commands is “everyItem”. What does this do? It gathers a list of every item of the kind you give a reference to; and it does so with an astonishing speed as well. When the list is gathered, you can inspect its various properties at leisure and decide what to do with each of the items.
everyItem(), and its often-partner getElements(), is a tough beast to master, and so I would not recommend this for starters :) It took Marc Autret not one but two blog articles to investigate it in full: On 'everyItem()' Part 1 and (no surprise) On 'everyItem()' Part 2. However, just to tease you, here is a variant of the script above that gathers every single formatted text span and then inspects each separate one for your applied character style.
cstyles = app.activeDocument.stories.everyItem().textStyleRanges.everyItem().getElements();
for (i=0; i<cstyles.length; i++)
{
if (cstyles[i].appliedCharacterStyle.name == “Emphasis”)
cstyles[i].underline = true;
}Theunis De Jong
MemberApart from a crucial missing detail, it's fairly easy to script.
.. at the moment its a slow trawl them with cmd+alt+J to change them ..
.. The missing detail is “What do you actually change, then?” :)
Theunis De Jong
MemberPlease be more specific:
Tried to change dictionary and spelling to swedish but it won´t work out for me.
What didn't work? How does one “change the dictionary” to Swedish? (A very common error is to 'change' the dictionary in Preferences, which changes just the preferences for that language, but does nothing else.)
Are you aware of the following index settings, called “Sort Options” in the Index panel menu?
Theunis De Jong
MemberUse a script from In-tools: https://in-tools.com/article/sc…..-indesign/
or a set of GREP Styles: https://colecandoo.wordpress.co…..und-holes/
-
AuthorPosts
