Copy link to clipboard
Copied
Hi all,
I am working on some process that produces unexpected results. It's a xml-based label production workflow and once the text is placed, I intend to fit it the best way. So basically I start setting a wide value and decrement through loop. My exit condition is that the story may not overflow.
My main concern is that overflow value seems updated quite late. Given the picture, it stopped at 10pts like obvisously it should have stopped sooner like 11 or maybe 12pts. But looking at my log, the overflow returns true for those values. However if I apply them by hand it's perflecty ok.
I also tried to call recompose and re-set reference for my story being tweaked (pointSize and leading) or using IDs but none of them changed anything.
So I am really confused here. How reliable overflow is and what would be the best approach for you in this case ?
//xe is a XMLElement Reference
var main = function(xe) {
var t = xe.texts[0].parentStory;
t.pointSize = 36;
t.leading = t.pointSize*1.2;
while ( t.overflows ) {
t.pointSize-=.5;
t.leading = t.pointSize*1.2;
}
}
Thanks in advance for your ideas.
Loic
Hi Loic,
All suggested codes above (including yours) work for me, so your script probably undergoes some (of the many) latency issues.
EnableRedraw turned off? Working on a ghost document? Background tasks behind the scene? Obscure XML-wise problem? Etc.
Anyway I still suggest recompose() as a secure starting point, even if another problem is involved.
That aside, here is how I'd have implemented this routine:
...var maximizePointSize = function(/*Story*/sto, a,o,tx,mid)
{
// Settings
// ---
Copy link to clipboard
Copied
Hi Loic,
You can try with frame overflows ...
//xe is a XMLElement Reference
var main = function(xe) {
var t = xe.texts[0].parentStory;
var f = xe.texts[0].parentTextFrames[0];
t.pointSize = 36;
t.leading = t.pointSize*1.2;
while ( f.overflows ) {
t.pointSize-=.5;
t.leading = t.pointSize*1.2;
}
}
Copy link to clipboard
Copied
Hi,
Alas, result is the same. The font size is reduced more than needed.
Loic
Copy link to clipboard
Copied
You write "However if I apply them by hand it's perflecty ok.", you change by hand pointSize and leading or just pointSize ?
Copy link to clipboard
Copied
If I do manually set both leading and size I can set a bigger text. The script decreases more than it should. It like the point size/leading combination returns an overflows while it shoudln't at some point.
Copy link to clipboard
Copied
Maybe a stupid idea ...
//xe is a XMLElement Reference
var main = function(xe) {
var t = xe.texts[0].parentStory;
t.pointSize = 6;
t.leading = t.pointSize*1.2;
while ( t.overflows == false ) {
t.pointSize+=.5;
t.leading = t.pointSize*1.2;
}
while ( t.overflows ) {
t.pointSize-=.5;
t.leading = t.pointSize*1.2;
}
}
Copy link to clipboard
Copied
Hi Loic
try following snippet I use sometimes.
but if `t.textContainers[0].recompose()` method didn't work well, it may not work.
var main = function(xe) {
var t = xe.texts[0].parentStory;
t.pointSize = 36;
t.leading = t.pointSize*1.2;
while ( t.lines.length !== t.textContainers[0].lines.length ) {
t.pointSize-=.5;
t.leading = t.pointSize*1.2;
}
}
thank you
mg.
Copy link to clipboard
Copied
Hi Loic,
All suggested codes above (including yours) work for me, so your script probably undergoes some (of the many) latency issues.
EnableRedraw turned off? Working on a ghost document? Background tasks behind the scene? Obscure XML-wise problem? Etc.
Anyway I still suggest recompose() as a secure starting point, even if another problem is involved.
That aside, here is how I'd have implemented this routine:
var maximizePointSize = function(/*Story*/sto, a,o,tx,mid)
{
// Settings
// ---
const MAX_SIZE = 36,
MIN_SIZE = 1,
LEADING_FACTOR = 1.2,
PRECISION = .1;
// Init.
// ---
a = [MIN_SIZE,MAX_SIZE];
o = { pointSize:MAX_SIZE, leading: MAX_SIZE*LEADING_FACTOR };
(tx = sto.texts)[0].properties = o;
if( !sto.overflows ) throw "You should increase MAX_SIZE";
// Dichotomy
// ---
while( a[1]-a[0] > PRECISION )
{
mid = (a[0]+a[1])/2;
o.pointSize = mid;
o.leading = mid*LEADING_FACTOR;
tx[0].properties = o;
sto.recompose();
a[+sto.overflows] = mid;
}
// Conclude
// ---
o.pointSize = a[0];
o.leading = a[0]*LEADING_FACTOR;
tx[0].properties = o;
};
@+
Marc
Copy link to clipboard
Copied
Hi Marc,
Thanks a lot for the hint. I was on a break last week and couldn't reply sooner. I am clearly on a enableRedraw false mode and not showing documents while processed.
I will give your snippet a try and let you know.
See you soon my friend,
Loic
Copy link to clipboard
Copied
Loic.Aigon wrote:
…
I am clearly on a enableRedraw false mode and not showing documents while processed.
…
Hm, couldn't that be an explanation for the strange behavior in your case?
enableRedraw set to false will speed things up for sure. Also not showing documents while processed.
But that comes with a price tag perhaps.
Uwe
Copy link to clipboard
Copied
Obviously. However Marc's snippet is really promising.
Can't wait to test it in production.
Copy link to clipboard
Copied
Bad news here, I think the latencies issues are unbreakable. It always end up with over-reduced texts.
I am thinking about using doing some geometry instead of looking at the overflowing property.
Thanks anyway,
Loic
Copy link to clipboard
Copied
Hello,
Finally that worked once I moved the "recompose" method on top on the while loop.
Thanks for your help all, I was getting crazy.
Loic
Copy link to clipboard
Copied
And here's my more lengthy and crude algorithm!
Copy link to clipboard
Copied
Hi Marc,
That seems to work perfectly on a dummy sample. I will try it at my client's place and will let youy know. But I am quite certain it will be also functional
Loic