Buzzwords effect in a mogrt - expression

I’m trying to build a mogrt file for PR which will work just like the out of the box buzzwords effect in AE.
So far, I have set up some 20 text layers which are hidden and will work as text fields and I have main text layer with ‘buzzwords’ expression that feeds from text fields 1-20.
My knowledge of expressions is rather basic but I got it to work somehow by altering the first line of expression to
buzz_words = (thisComp.layer(“1”).text.sourceText +’|’+ thisComp.layer(“b”).text.sourceText+’|’)
I realise if I set this up for 20 text layers, this would be rather lengthy code, do you have any recommendations for making this a little bit less so?
Thanks in advance.
(raw code of Buzz words effect below)
buzz_words = "One|Two|Three|Four|Five|Six|Seven|Eight|Nine|Ten";
split_buzz_words_array = buzz_words.split('|');
buzz_frame_rate = effect("Buzz Frame Rate")(1);
buzz_frame = Math.floor(time * buzz_frame_rate);
buzz_index = buzz_frame % split_buzz_words_array.length;
split_buzz_words_array[buzz_index];

Related

What is wrong with this PDF file?

I have to work with a PDF form created by a person unknown to me. Why did the program with which the form was created (Word + PDF export?) split the term "Stunde" into "S", "t" and "unde" in line 6909 of the decoded PDF? There is no visual break between the three parts.
/TT1 1 Tf
11.04 0 0 11.04 59.16 476.1203 Tm
(Datum)Tj
/C2_1 1 Tf
<0003>Tj
/TT1 1 Tf
(der)Tj
0.424 -1.315 Td
(Tätigkeit)Tj
-0.0022 Tc 0 11.04 -11.04 0 261.24 437.7203 Tm
[(Ve)-4.6<7267fc74>-4.2(ungssat)-4.2(z)]TJ
/C2_1 1 Tf
0 Tc <0003>Tj
/TT1 1 Tf
-0.0021 Tc 0.935 -1.315 Td
[<2880>-6.1(/)-7.2(S)0.8(t)-4.1(unde)-4.5(\))]TJ % <<< the important line
0 Tc 11.04 0 0 11.04 340.92 468.8003 Tm
(Anlass/Art)Tj
/C2_1 1 Tf
resulting in
[]
To get the source code above, I decoded the PDF file as described here. I have no know-how concerning the PDF file format.
Background: I had to replace the word "Stunde", it drove me crazy to find the place where "Stunde" was written (in parts) within the source code, since no free PDF editor seems to be able to work with horizontal text without problems.
Academic Bonus questions: Is it possible to set the sum over a column as default value for a form field? (Modifiable; changed every time the column is changed.) Why was I able to replace "Stunde" with "Einsatz" without making the PDF file corrupt due to now irregular offsets?
Why did the program with which the form was created (Word + PDF export?) split the term "Stunde" into "S", "t" and "unde" in line 6909 of the decoded PDF?
As #gettalong mentioned in his answer, in your case this most likely has been done to apply kerning.
If you start looking into the outputs of some other PDF producers, you'll see that this export from Word actually is very unobtrusive in regard to splitting words:
there are PDF producers that draw each character individually after explicitly setting the text matrix for it, and
there also are PDF producers that have the width information for the characters of the used fonts set to zero and use the numbers in TJ instructions to forward the current text matrix between characters accordingly.
And this doesn't cover all the variants to be found, not by far...
Thus,
I had to replace the word "Stunde", it drove me crazy to find the place where "Stunde" was written (in parts) within the source code
in your case replacing actually was a fairly trivial task...
Is it possible to set the sum over a column as default value for a form field? (Modifiable; changed every time the column is changed.)
If all the column values in question are stored in form fields, you can use JavaScript to recalculate sums after form changes. To have it serve as "default" only, you can use some other (hidden) field for a flag whether the field has already been touched. Beware, though: JavaScript is not supported by all PDF viewers. Furthermore, the JavaScript object model for PDF is not specified in an independent (like ISO) specification but in an Adobe one which can make interpretation of the specification biased.
Why was I able to replace "Stunde" with "Einsatz" without making the PDF file corrupt due to now irregular offsets?
As we don't know how exactly you applied the changes, this obviously is hard to tell.
Most likely, though, you did corrupt the PDF and the PDF viewers you opened it in merely repair the corruption under the hood. There is a strong tendency in PDF viewers to do such under-the-hood repairs without informing the user; the result is that a large part of the PDFs in the wild actually being broken.
You don't see a visual break but the standard distance between "S", "t" and "unde" has been changed nonetheless. This is done by PDF writers that support e.g. kerning so that the word appear nicer. This is the reason why it is split that way.

MigraDoc - extra and unwanted NewLines

I have a code, where I create a paragraph with 4 lines, 3 of them use tabs to separate row labels and parameter. Astonishingly, a code that worked flawlessly in another form is giving me big headache in current form, even though it is practically 100% identical. Two extra lines appear between line label and a parameter.
Dim ParPara As New Paragraph ' create new paragraph
Dim formtext As New FormattedText
formtext.Bold = True
formtext.AddText("ABC 12345")
Dim formtext2 As New FormattedText
formtext2.Bold = True
formtext2.AddText("163658468435831484")
Dim formtext3 As New FormattedText
formtext3.Bold = True
formtext3.AddText("PARAMETER 1")
ParPara.Add(formtext4)
ParPara.AddLineBreak() ' intentional line break at the end of line
ParPara.AddText("Row Header 1:")
ParPara.AddTab()
ParPara.Add(formtext)
ParPara.AddLineBreak() ' intentional line break at the end of line
ParPara.AddText("Row Header 2:")
ParPara.AddTab()
ParPara.Add(formtext2)
ParPara.AddLineBreak() ' intentional line break at the end of line
ParPara.AddText("Row Header 3:")
ParPara.AddTab()
ParPara.Add(formtext3)
...
TableRowHead0F.Cells(1).Add(ParPara)
I even compared in-memmory content of the paragraph and it's 100% identical in both forms, one working flawlessly and another one inserting extra NewLine breaks:
The in-memmory structure is correct:
The migradoc styles are set identically in both forms (working and failing) too.
Anyone has any ideas why this is happenning?
EDIT: As suggested, I compared MDDDLs and I see no differences:
I don't know, if there can be some context (cell style?) affecting this, but it's really odd. Not the first time I see something like this with MigraDoc...
EDIT 2:
The problems was in switching an order of lines of definition of one style, I had 2nd line of this code at the end:
Dim sStyle As Style = PruvDoc.Styles(StyleNames.Normal)
sStyle = PruvDoc.Styles.AddStyle("Quest", "Normal")
sStyle.ParagraphFormat.TabStops.Clear()
sStyle.ParagraphFormat.TabStops.AddTabStop("9cm", TabAlignment.Left, TabLeader.Dots)
...and that meant that tab stops were applied to the "Normal" style, instead "Quest". Against expectation, it was defined well after the part, where the problems ocured(good to know).
A useful approach to investigate such problems: You can create MDDDL files for the version that works and for the version that does not work and then compare the MDDDL files.
See here:
http://pdfsharp.net/wiki/MigraDocDDL.ashx
MDDDL files are somewhat readable and can be used to check what you actually add to your document - even if you only have a version that does not work as expected.

Configure larger limit of columns on Format module

The Format module
The Format module is used to model and combine pretty printers with a syntactic extension that allows typed formats and it helps a lot when you are writing something like a code generator or a data structure printer.
The problem
However, there is a limit of 78 columns that is initialized on the margin of the formatter and will pull to the left anything that takes more than this limit.
I'm printing a lighter version of a Yojson.Basic.json program using the Format module, but when the input is too large, the output is collapsed, and that is not really "prettily".
Preview
Here is how it is is formatted when it is short:
Here is how it is formatted when the indentation becomes too large
I've been trying to exceed and configure this limit to 120 columns, but didn't have any success.
What have I tried?
Using Format.pp_set_margin ppf 120 to reconfigure
Using Format.pp_set_max_indent to a larger value
But they doesn't seem to have any effect and there is no documentation easily available about this limit. I've discovered it only by reading the source code.
What am I doing?
let string_of_cst program =
let ppf = Format.str_formatter in
(* I've enabled colors. *)
Format.pp_set_tags ppf colors;
Format.pp_set_formatter_tag_functions ppf with_colors;
(* [print_json] is my printer. *)
print_json ppf program;
(* Get string out of printer. *)
Format.flush_str_formatter ()
How can I configure a larger limit?
The issue is that the values for margin and max_indent are implicitly constrained to the cone 1 < max_indent < margin and the function set_max_indent silently fails and does nothing if this constraint is not respected.
To avoid this issue, in OCaml ≥4.08, it would be possible to use the new set_geometry function that requires to set both value simultaneously and fails with an exception if the required max_indent is greater than the margin.
Otherwise, you should always set both values at the same time, and always in the order
margin first, and max_indent second. If you don't know which value to chose for max_indent, margin - 10 is generally an alright choice.

Other options to resize barcode for zebra printer using ZPL?

I want to print a Code 128 barcode with a Zebra printer. But I just can't get exactly where I want because the barcode is either too small or too big for the label size of 40x20 mm. Is there anything else I can try besides using the ^BY (Bar Code Field Default) module width and ratio?
^XA^PQ2^LH0,0^FS
^MUM
^GB40,20,0.1,B^FS
^FO1.5,4
^BY0.2
^BCN,10,N,N
^FD*030493LEJCG002999*^FS
^FO8,15
^A0N,3,3
^FD*030493LEJCG002830*^FS
^MUD
^XZ
Above script gives me a label that looks like this:
But when I just decrease the module width to 0.1 (which is the lowest) the barcode becomes too small and may be problematic to scan with a hand scanner:
Code-128 is a fixed-ratio code, so you would appear to have the choice of two sizes. You may be able to solve the problem by using a 300dpi printer in place of a 200.
If you can change the format (and I'm intrigued by the barcode and readable being different values) then you could save a little by printing one number-sequence and one alpha-sequence, as an even count of numerics will be encoded as alphabet C so you'd save one change-alphabet element.
Do you really need the * on each end?
Otherwise, perhaps code 39 (which prints the * if you use the print-interpretation-line option) would suit your purposes better.
Another Possibility is to do on the fly code-set changes, Try something like
^XA^PQ2^LH0,0^FS
^MUM
^GB60,20,0.1,B^FS
^FO1.5,4
^BY0.2
^BCN,10,N,N
^FD>:*>5030493>6LEJCG>5002830>6*^FS
^FO8,15
^A0N,3,3
^FD*030493LEJCG002830*^FS
^MUD
^XZ
This will allow less symbols to encode your data
If you can structure content to have all the alpha chars a one end or the other.
or (Depending on your firmware) you could use auto ^BCN,10,N,N,N,A

Sphinx and reStructuredText: multiple code highlighting in a single block

I am new to Sphinx. I am writing some documentation for embedded UDFs that requires a code block to contain 2 languages (e.g. SQL and python). At present I can only see how to have a single highlight language in a block.
Is it possible to "switch" languages within a block? Below is an example of reStructuredText that results in 3 code block that I want to merge into one.
Simply removing the second and third "::" doesn't work.
.. highlight:: sql
::
SELECT * FROM
EXTERNAL SCRIPT(
.. highlight:: R
::
#Some R markup
MEANS = matrix(runif(nclust*ndim)*sqrt(nclust)*sep, nrow = nclust)
VARS = matrix(runif(nclust)*ndim, nrow = nclust)
ps = 1:nclust
ps = ps/sum(ps)
.. highlight:: sql
::
)
FROM myshema.mySQLtable
I am 99% sure that this cannot be done by default, and your solution of using separate 'highlight' blocks is the standard procedure to show multiple languages.
I believe that this is for the best anyway as mixing code in one block is usually a bad idea as it can confuse readers.
Also, when converting reStructuredText into HTML for example, a style sheet is used to make everything look pretty, and a default style sheet is included. If you do some research, I'm sure you could edit that style sheet or make your own, perhaps making the 'border' invisible and the 'margin-bottom' zero pixels for 'highlight' blocks.
You can try this extension to have different languages in tabs:
https://bitbucket.org/birkenfeld/sphinx-contrib/src/c30b46a0a1b5c21ec9977e6abc598d0654316ac2/examplecode/?at=default

Resources