I'm trying to figure out how to print out dynamic content without creating a physical TXT file to print the data from.
In other words, I'm calling mytext.php and writing the contents out ... mytext.php looks like this:
<?php echo "Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.";
And the PDF is generated with literally ALL of that within the text ... so <?php echo "Lorem..."
What's the best way to print dynamic content?
What I usually do is assemble the dynamic content (query the db, using post-variables ...) from within the script that generates the pdf.
If that is not necessary and the php-script you're calling outputs plain text, you could use output buffering.
There is a question that has already been asked here that holds the answer:
Read echo'ed output from another php file.
So basically, you put the output in a variable and using the FPDF Write, Cell or Multicell-function, place it inside your pdf.
Related
Is there a way to edit the raw text from a PDF without any special paid software?
So there are PDFs with highlightable text. I assume that the text is stored somewhere in the file.
I tried to just drag & drop a PDF into vscode but it just showed me unknown characters; even a little of meta text but if I edit the meta-infos, the file gets mostly corrupted.
Apart from that, I could not find any of the text contents of my desired PDF in vscode-editor.
Does someone know if there is a solution like inspecting and changing the source code somehow without a special software? I want to edit the contents; not the meta-infos.
(I use macOS)
The text you see on a pdf page can be constructed in dozens of different ways, actually there are millions of users, using potentially hundreds if not thousands of different methods.
Update
The question is MacOS but for native cross platform you need to work in mime text/pdf to be universally useful. But by way of example how thats possible specifically in windows its possible to write line by line using say cmd here is a snippet of what was a few dozen lines :-)
echo %%PDF-1.0>demo.pdf
echo %%µ¶µ¶>>demo.pdf
echo/>>demo.pdf
for %%Z in (demo.pdf) do set "FZ1=%%~zZ"
echo 1 0 obj>>demo.pdf
echo ^<^</Type/Catalog/Pages 2 0 R^>^>>>demo.pdf
echo endobj>>demo.pdf
echo/>>demo.pdf
For the fuller "Feature Creep"ing of now over more than a 100 lines and counting see
https://github.com/GitHubRulesOK/MyNotes/raw/master/MAKE-PDF.cmd
However although plain text could be the simplest it is rarely used except to prove a conceptual point that it is possible. The rest of the time "Special Software" as you call it (a pdf generator/editor) will be used to compress the file objects, most frequently as different optimal binary streams.
So some text may be scanned pixels whilst other text may be line shapes that look like letters, or at other times plain letters without fonts but a named style, or even letters with the font included (embedded) in the file (the preferred option).
In many ways each page may be built different to the others and thus no two pdfs generally will use the same structure unless like a bank statement using a format that does not change much from month to month, even if the balance wobbles about.
So in summary the tool that will work best is the one that covers every single permutation that Adobe dreamed of, and still keep the result a valid Adobe PDF.
Thus Acrobat PRO 3D is on my shelf (even if not used from one year to the next)
There are many cheaper editors and ones I will use more often for small mods are Tracker Xchange and FreePDF PRO and both have different limitations.
Your choices for MacOS will be more limited thus search for the best you are willing to pay for.
I am using BarTender to design a set of labels to print to ZPL printers. One of my requirements is for a Royal Mail Mailmark label which uses the CMDM Barcode.
We output to file using alias values in the label fields.
We then run an application which swaps out the alias values and replaces them with the database values we actually want to print.
The issue is when I open label designs previously used to create the template files, the output (which previously was in simple text form) has now been outputted into a DGR....GRF format. (Please see below)
Unfortunately the CMDM barcode on BarTender is designed so that I can't just use an alias. That is my understanding anyway.
^FT407,1137
^A0B,28,34^FD*ship_to_zip^FS
^FT659,1148
^A0B,25,31^FDOur Reference ^FS
^FT564,1148
^A0B,25,28^FDCustomer Reference^FS
^FT595,1148
^A0B,25,28^FD*po_nbr^FS
^FT697,1148
^A0B,25,28^FD*distro_nbr^FS
^FO553,300
^BY2^BCB,124,N,N^FD>:*carton_nbr^FS
^FO28,72
^XGR:SSGFX000.GRF,1,1^FS
^ISR:SS_TEMP.GRF,N^XZ
~DGR:SSGFX001.GRF,1352,13,:Z64:eJydk9ERBCEMQtMB/XdJBxzE3D93ruP6nDHBoMDvjYBEDoZqYeSF8TiCSqC7vD2IEvK5Z3cNTkRqZ2phnM4zKyZbSIic0YprcIAMLrpqUHQSV8UOUo/dij1dBTGXCaT1oAIrdEp6Kbeig/jlCCZNC7H3Sk6U4ADMEV3+TdrAXoxLjRL4HoUjjFqIOM+2/i2k7PEY++/A+fTd2cKz+ElVCTN7XVdqC/b1pK4FFeRlnNT3agv4p30AH1GDtw==:D4A2
^XA
^ILR:SS_TEMP.GRF^FS
^FO242,308
^XGR:SSGFX001.GRF,1,1^FS
^PQ1,0,1,Y
^XZ
Has anyone come across this problem or know of a ZPL command I can use for this type of Barcode?
The main issue is Royal Mail want the Latch to C40 at the beginning of the barcode. When I print a standard 2D DataMatrix barcode, this latch to C40 code appears in the middle of the code.
Just need to know if I can move it to the beginning of the code.
Thanks
The ZPL datamatrix command does not support manually encoding the code words, which is what you need to force a latch to C40. But you can use BarTender to get around this. (I am not associated with Seagull Scientific, but my clients often use it.)
Instead of programmatically modifying the BT format file directly, you should be generating a data file that provides the field data for the label. BarTender calls this "data file integration".
See this video for more information: https://support.seagullscientific.com/hc/en-us/articles/227353867-Print-Document-Using-a-Data-File-Integration-Video-6-31-
I want to convert the following *.md converted into proper LaTeX *.tex.
Lorem *ipsum* something.
Does anyone know lorem by heart?
That would *sad* because there's always Google.
Expected Behavior / Resulting LaTeX from Pandoc
Lorem \emph{ipsum} something.
Does anyone know lorem by heart?
That would \emph{sad} because there's always Google.
Observed Behavior / Resulting LaTeX from Pandoc
Lorem \emph{ipsum} something. Does anyone know lorem by heart?
That would \emph{sad} because there's always Google.
Why do I care?
1. I'm transitioning a bigger git repo from markdown to LaTeX, and I want a clean diff and history.
2. I actually like my LaTeX with one sentence-per-line even though it does not matter for the typesetting.
How can I get Pandoc to do this?
Ps.: I am aware of the option hard_line_breaks, but that only adds \\ between the two first lines, and does not actually preserve my line breaks.
Update
Since pandoc 1.16, this is possible:
pandoc --wrap=preserve
Old answer
Since Pandoc converts the Markdown to an AST-like internal representation, your non-semantic linebreaks are lost. So what you're looking for is not possible without some custom scripting (like using --no-wrap and then processing the output by inserting a line-break wherever there is a dot followed by a space).
However, you can use the --columns NUMBER options to specify the number of characters on each line. So you won't have a sentence per line, but NUMBER of characters per line.
A much simpler solution would be to add two spaces after "...something.". This will add a manual line break (the method is mentioned in the Pandoc Manual).
I figured out another way to address this problem – which is to not change the original *.mds (under version control), but to simply read them in and to have them "pandoced" when building the PDF.
Here's how:
Some markdown.md in project root:
Happy one-sentence-per-line **markdown** stuff.
And another line – makes for clear git diffs!
And some latexify.tex in project root:
\documentclass{article}
\begin{document}
\immediate\write18{pandoc markdown.md -t latex -o tmp.tex}
\input{tmp.tex}
\end{document}
Works just dandy if you have some markdown components in a latex project, e.g. github READMEs or sth.
Requires no special package, but compilation with shell-escape enabled.
I was trying to build a graph connecting actors using the movies they have worked for using IMDB ftp data.
However I only wanted to use movies (title type :- Feature Films) as connections.
I downloaded the ftp data from IMDB. However I was not able extract the title type from the files. I wanted to know if any body has tried to sort the ftp data provided by IMDB based on title type and how did they differentiate.
The title itself will tell you what kind of show you're dealing with.
If it ends with "(TV)" it's a TV movie (a single episode, produced for TV).
If it ends with "(V)" it's a video movie (straight to video).
If it's surrounded by quotes and ends with "(mini)" it's a tv mini series. (NOTE: I think that this category is no longer present, in the plain text data file).
If it's only surrounded by quotes, it's a tv series.
If the title is surrounded by quotes and ends with another titles enclosed in curly brackets, it's an episode of a tv (mini or not) series (inside the brackets there's the title of the episode - if known - or the #seasonNR.episodeNR or the air date).
anything else, is a movie.
A special case are tv series episodes marked with {{SUSPENDED}}, which means that the episode was never produced, but it was planned and maybe it will be done in the future.
Notice that these rules apply only to the plain text data files that you can download from the FTP servers. Since some years, on the web site a different of rules are followed.
I've done a lot of research on the subject, being the main author of IMDbPY (by the way: give it a look, since it may be useful to you to import these information into a SQL db).
I was wondering if there is a good argument for or against using backgrounds in cucumber when compared to using tags and hooks.
Having a logged in user before the start of a test could go either like this:
Background:
Given that I am logged in
Scenario: Lorem ipsum sit amet dolor
[...]
or like this:
#login
Scenario: Lorem ipsum sit amet dolor
[...]
+
before(#login) do
visit('/admin/login/testuser')
end
Any idea when to favor one over the other?
Background is useful when you provide common customer-readable (non technical) background for your scenarious. It is worth using it if you want to be explicit about this initialization in the text of your Feature.
But sometimes teardown (and setup) logic is an implementation details and is implemented in Before, After or Around hooks (because reader of your spec won't need to know about these technical things).
Summary: use Background if you want to inform reader of your spec of the background and use hooks when background is an implementation details.
In you example Background is the best choice.
Definitely the former (IMHO), since it captures everything in the universally readable Gherkin feature file. The tags are only really there to help the runner - they are implementation level. What you describe here is part of the description of what is going on.