Forum Replies Created
-
AuthorPosts
-
Theunis De Jong
MemberApparently, none of the “entire range of our user base” (quoth Michael Ninness) are using indexes :-(
Oh — and I said
For me it's a snap to re-write those scripts to “manually” generate a correct index, sorted and all.
… well … Besides being +700 pp., it's also about Eastern European writers. After I finally had generated a correct index, with all the right page numbers in the right order (and even concatenated ranges like “11,12,13” into “11-13” — another trick that might leave Adobe engineers baffled by my ingenuity) … entries such as “?apek, Karel” (the Czech playwright that coined the term “robot” for a 'mechanical worker') appeared at the very end of the index. Javascript is not good at Unicode sorting …
So I had to implement on-the-fly removing of accents as well as a custom “sort-by” … But I think I got it, after several hours of frantic trying. There are still a few weird cases but at least everything seems to be there.
Theunis De Jong
MemberIn the Help?
But … you're in for some treats! (Well — as long as you don't need indexes …)
* GREP is a programmers' way of finding text; it's vastly superior to ID's “normal” searching (it takes some time to get the basics, but after that …)
* You can even apply character styles automatically. Imagine every time you see a word “Wow!” you have to make it Comic Sans. Put this in a GREP style and ID will automatically do that for you!
* Ehm. … Did you read all of InDesignSecrets.com of the past 5 years?
Theunis De Jong
MemberIt's possible, but it highly depends on your InDesign version how easy it is.
For CS4 and later, check the Help on Cross-References. That's one way to do it.
Theunis De Jong
MemberApparently, none of the “entire range of our user base” (quoth Michael Ninness) are using indexes :-(
Oh — and I said
For me it's a snap to re-write those scripts to “manually” generate a correct index, sorted and all.
… well … Besides being +700 pp., it's also about Eastern European writers. After I finally had generated a correct index, with all the right page numbers in the right order (and even concatenated ranges like “11,12,13” into “11-13” — another trick that might leave Adobe engineers baffled by my ingenuity) … entries such as “?apek, Karel” (the Czech playwright that coined the term “robot” for a 'mechanical worker') appeared at the very end of the index. Javascript is not good at Unicode sorting …
So I had to implement on-the-fly removing of accents as well as a custom “sort-by” … But I think I got it, after several hours of frantic trying. There are still a few weird cases but at least everything seems to be there.
Theunis De Jong
MemberIn the Help?
But … you're in for some treats! (Well — as long as you don't need indexes …)
* GREP is a programmers' way of finding text; it's vastly superior to ID's “normal” searching (it takes some time to get the basics, but after that …)
* You can even apply character styles automatically. Imagine every time you see a word “Wow!” you have to make it Comic Sans. Put this in a GREP style and ID will automatically do that for you!
* Ehm. … Did you read all of InDesignSecrets.com of the past 5 years?
Theunis De Jong
MemberWhy not try it!
If you run out of patience before InDesign runs out of memory, let us all know how much you managed to squeeze in.
(My bet is … well … don't know. For tables, I think I ran into a limit somewhere — it may have been 100 columns. I wouldn't be surprised if ID has no problems with thousands of fields, for a plain data merge.)
Theunis De Jong
MemberPeter Kahrel's e-book “GREP in InDesign CS3/CS4” has occasionally been called 'best value for money': https://oreilly.com/catalog/978…..596557348/
Theunis De Jong
MemberIt is rather odd. You are sure there are no other codes involved? (Soft line breaks, or non-breaking spaces, to name a few that could cause this.)
I suspect it's something to do with the paragraph composer trying to fill the column width on most lines, even if that means leaving some drastically short.
Nope — well, fairly sure of a “nope”. As I understand the paragraph composer, on your strange 3-liner it ought to settle for at least 2 fairly equal lines, followed by whatever remains. The “balance ragged lines” option forces the behavior you propose, but it's highly inappropriate for list of names (if only because it might decide to put each name on a line of its own, just because there is one long name in the list).
Theoretically, you ought the exact same behavior if you replace space-not-after-a-comma with a non-breaking space. Your GREP style method is superior since it doesn't need anything else; but can you try and see if it yields the same result on that paragraph?
(Footnote: it might also work to switch to the Single-line composer. Perhaps the very intelligent Paragraph Composer does get confused by this …)
Theunis De Jong
MemberWhy not try it!
If you run out of patience before InDesign runs out of memory, let us all know how much you managed to squeeze in.
(My bet is … well … don't know. For tables, I think I ran into a limit somewhere — it may have been 100 columns. I wouldn't be surprised if ID has no problems with thousands of fields, for a plain data merge.)
Theunis De Jong
MemberPeter Kahrel's e-book “GREP in InDesign CS3/CS4” has occasionally been called 'best value for money': https://oreilly.com/catalog/978…..596557348/
Theunis De Jong
MemberIt is rather odd. You are sure there are no other codes involved? (Soft line breaks, or non-breaking spaces, to name a few that could cause this.)
I suspect it's something to do with the paragraph composer trying to fill the column width on most lines, even if that means leaving some drastically short.
Nope — well, fairly sure of a “nope”. As I understand the paragraph composer, on your strange 3-liner it ought to settle for at least 2 fairly equal lines, followed by whatever remains. The “balance ragged lines” option forces the behavior you propose, but it's highly inappropriate for list of names (if only because it might decide to put each name on a line of its own, just because there is one long name in the list).
Theoretically, you ought the exact same behavior if you replace space-not-after-a-comma with a non-breaking space. Your GREP style method is superior since it doesn't need anything else; but can you try and see if it yields the same result on that paragraph?
(Footnote: it might also work to switch to the Single-line composer. Perhaps the very intelligent Paragraph Composer does get confused by this …)
Theunis De Jong
MemberIf you can think of another way to identify potentially bad images, call me in the morning. I actually was thinking of adding a drop shadow :-) (I couldn't figger out how to add it to a style with a script.)
There are not that very much options, other than adding some effect. Perhaps a dialog that let's you browse through the “suspicious” list?
Theunis De Jong
MemberI agree it cannot be scripted to automatically adjust bounding boxes. A script doesn't have access to the 'contents' of a placed image, thus it cannot check if it's just whitespace that got cropped, or an incredibly important atom just got deleted.
A script can be aware of an image being cropped, but (fortunately!) you thought of mentioning that might also be valid. So you are correct: only all cropped images can be flagged, and it's up to the operator to decide whether it's wrong or not.
Hold on while I do some testing. (Insert telephone waiting muzak here.)
…
(di da di da … got something … almost done …)
Okay — finding suspicious items is not the problem. How they should be marked, however, is. This javascript creates a bright red “Warning” color and a “Warning” object style with a thick fat red line, and applies it to the frame. So — do not use this if you are already using another object style on your images! (In that case I'd like to hear from you what other options there are to mark items…)
try { app.activeDocument.objectStyles.add({name:”warning”}); } catch(_) {}
try { app.activeDocument.colors.add ({space:ColorSpace.RGB, colorValue:[255,0,0], name:”Warning”}); } catch (_) {}
warningStyle = app.activeDocument.objectStyles.item(“warning”);
warningStyle.properties = { enableStroke:true, enableFill:false, strokeColor:app.activeDocument.swatches.item(“Warning”), strokeWeight:5, strokeAlignment:StrokeAlignment.INSIDE_ALIGNMENT};
imageList = app.activeDocument.allGraphics;
found = 0;
for (im=0; im<imageList.length; im++)
{
try { if (isImageCropped (imageList[im].geometricBounds, imageList[im].parent.geometricBounds))
{ found++; imageList[im].parent.appliedObjectStyle = warningStyle; } } catch (_) { found++; imageList[im].parent.appliedObjectStyle = warningStyle; }
}
alert (“Found “+(found?found:”no”)+” suspicious frame”+(found==1?””:”s”));
function isImageCropped (img, frame) {
if (img[0] < frame[0] || img[1] < frame[1] || img[2] > frame[2] || img[3] > frame[3]) return true; return false; }
Theunis De Jong
MemberIt can be made slightly more solid since you know what items may follow the “in”. Thus you can avoid the likes of “in the absence of” :-D
bin (honor|memory) .+
Theunis De Jong
MemberIf you can think of another way to identify potentially bad images, call me in the morning. I actually was thinking of adding a drop shadow :-) (I couldn't figger out how to add it to a style with a script.)
There are not that very much options, other than adding some effect. Perhaps a dialog that let's you browse through the “suspicious” list?
-
AuthorPosts
