b.LOREM

[trych]

Hi there,
after a little break here, I am back with lots of input, ideas and feedback from the course I am teaching. I will therefore open a few issues now, with suggestions for improvement. Btw, the course is going great, lots of people learning programming from scratch and making nice progress.

The first one is really simple, but I think for a heavily typography related project like basil.js it would be nice to have a lorem ipsum constant, that simply contains the lorem ipsum string. In the course, demonstrating how to work with text I need to grab some text all the time and I am getting tired of typing "Hello, I'm Timo." and "afölsdkjföalsdjfö aljdfölakjs". ;) Would be useful for sample scripts, too.

pub.LOREM_IPSUM = "Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.";

What do you think?

[ff6347]

Do you know the placeholder text feature of InDesign? It fills a textframe with text. You can even add your own text. https://indisnip.wordpress.com/2010/08/12/fill-text-frame-with-placeholder-text/

[trych]

I knew somebody would mention the placeholder text feature now. 😉

However, the proposed constant serves a different purpose. It reliably gives the same text for everybody using it every time and it also can be an advantage that not the entire text frame gets filled with placeholder text. Especially when experimenting with growing point sizes etc. you will always run into overflow text right away, when your entire text frame is filled.

I mean b.placeholder() could be a thing as well, but this is about b.LOREM_IPSUM. Or simply b.LOREM?

[ffd8]

Great idea to bring this into the scripting realm. It would be great for demos and just testing things out. I'm also a fan of b.placeholder(), since having a preset/fixed amount of lorem would likely be too little/much in each case. The other advantage of placeholder is the 'randomness' of the text, so it doesn't look copy+paste.

Something like:
b.placeholder(ref_textframe);

Perhaps a b.lorem(#lines) could also be useful, but harder to imagine scenarios.

[trych]

Perhaps a b.lorem(#lines) could also be useful, but harder to imagine scenarios.

Yes, I thought about that, too. But how about a b.repeatString() instead? Then this could be used if I need it several times and b.LOREM could be kept a simple constant.

[ffd8]

The flexibility of placeholder is hard to beat.

Next to b.placeholder() - perhaps a b.fillText("text_string") would be useful – which would adjust font size, spacing, etc. to fill a given textFrame with a string of text. I've (and surely many others) have already made little 'while ++ size' functions testing for overflow text.. but builtin could be useful?

[trych]

The flexibility of placeholder is hard to beat.

Then b.placeholder() could maybe just take an optional argument for a custom text? So you could do anything from b.placeholder(tf, "I love basil.js.");, over b.placeholder(tf, b.LOREM) to b.placeholder(tf, b.loadString("aReallyLongBook.txt")).

b.fillText() in the way that you describe it, I would rather name b.fitText(), else it sounds like text will be repeated until the frame is filled. Yes, this function could also be useful. So, it would be b.fitText(textContainer, "textString") then, right? And textString could be optional, if I rather want to use the already existing text in the container.

[trych]

Ok, to summarize, we have three different things now (will split these into separate issues, as soon as we know which ones we like):

1. b.LOREM
2. b.placeholder()
3. b.fitText()

I am fine with all three. What about the others?

[ffd8]

Hmm I think the previous comment for b.placeholder() - gets too mixed up when one can also feed custom text into it. The usefulness of placeholder type is the non-text (lorem) for the appearance of unknown text. The proposed way above could be broken into two separate functions (since what you proposed is also very relevant.. since until now one must use textFrame.contents = "..." or b.typo()). Sooo I propose the following:

1. b.placeholder(tf) - fills textframe with indesign's lorem/placeholder text.
2. b.placetext(tf, "string") - puts text into selected textframe.
3. b.placeimage(container, img) - if we have text, should also have img
4. b.fitText(tf) - fits text already within given textframe. Not necessary but fancy.

The exact wording of the functions can be workshoped.. is b.placeText()/b.placeImage() better since they contain two words?

As helpful as it is that your idea for LOREM started this thread, I unfortunately can't see the need for such a constant with that # of sentences fixed text.

[trych]

Hm, for placing text or placing images, I would actually use the proposed b.addToText() (that I am currently working on and is kind of on hold until I get some feeback on the style issues).

• b.placeholder(tf) sounds good to me.
• b.fitText(tf) as well, there is the opportunity that we could let the user allow to pick the property used to fill the textFrame (pointSize, tracking, horizontal scale etc.). I wrote an algorithm like that in my bachelors project, it is not quite production ready though. Will open an issue to discuss this further.

As helpful as it is that your idea for LOREM started this thread, I unfortunately can't see the need for such a constant with that # of sentences fixed text.

😞 That is actually exactly the point that it is a fixed text that always has the same length and content. And also to have a a quick text that does not fill the text Frame necessarily.

It just provides a quick, intuitive string for testing and I think would be great for teaching. Want to quickly demonstrate how to use b.split() to split a string? Use it to split b.LOREM. No need to create a textFrame first. Same goes for any other string operations.

Also for debugging something it can be helpful to have a student's script with an exact string in it that is exactly reproduced every time the script is run, so changing parameters like different hyphenations etc. don't change the outcome of the script.

[trych]

Another scenario might be, when you need to actually use the same text in different parts of the document, i.e. that means you need to place it in two or more text frames. Then placeholder text would not work, since the text is different the second time.

[ffd8]

Haha - OK.. I slowly give in due to the reasons of demonstrating functions like split or debug. Although I've always been annoyed by TextMate's same 4 sentences of LOREM each time one uses it. Other opinions?

Proposal for fitText() w/ various type settings sounds great. It could be connected to the b.typo function to accept any of those attributes which are number based and regularly check for overflow:
http://jongware.mit.edu/idcs5.5js_html/idcs5.5js/pc_Text.html

The placeText/placeImage might still be useful for those who are just generating shapes and want to fill them with content. This nice 'addToText()' function you're working on is more complex than a handful of instances I can imagine. It's just one line of code for each in the InDesign JS syntax, but probably useful to have a basil.js style function for it.

[ff6347]

All sounds pretty useful even the b.LOREM constant.

[b-g]

Nice ideas! +1 from end for:

1. b.LOREM
2. b.placeholder()
3. b.fitText()