I am trying to left align some columns in a few of my tables. Most of the time this works no problem, but other times, the columns selected with:
ft <-align(ft, j=1:2, align = "left", part = "body")
ft <-align(ft, j=4:6, align = "left", part = "body")
look correct in the Rstudio viewer. I used a loop to make 39 tables and want to add them to a word document using officer
However, when printed to a word doc using:
doc <- read_docx() %>%
body_add_flextable(tab0)
body_add_break(doc, pos="after")
for (i in 1:38) {
body_add_flextable(doc,get(paste0("tab", i)), align = "left")
body_add_break(doc, pos="after")
}
print(doc,target=documentname)
it center aligns the columns (only changes those that were left aligned). When I click on the text, it says that they are left aligned, but then I center and re-left align and that fixes the issue. I have only noticed the issue which character variables
I tried triming whitespace with
trimws() before I make the flextable with no luck.
I tried other alignments and the issue only seems to occur with left alignment.
I don't believe my code to be wrong, since it works for my other tables. Therefore, I think trying to make reproducible code would be a waste of time.
Therefore, I'm assuming the text itself is causing the issue? Does anyone know what could be wrong with the character variables themselves? Or any other ideas?
Fixed it...
Somewhere within my flextable manipulation this leading white space was added.
So trimming white space before didn't do anything. Had to trim right before naming my table (within a loop). Here is the loop I used to correct it.
for (j in 1: length(ft[["body"]][["content"]][["content"]][["data"]])){
ft[["body"]][["content"]][["content"]][["data"]][[j]][["txt"]] <- trimws(ft[["body"]][["content"]][["content"]][["data"]][[j]][["txt"]])
}
Related
please see the image below for two examples of what is to be achived
the alignment should be on the Center Y of the first lines of each UILabels and should work regardless of font size or font. currently we have implemented this with different constraints to the top of the super view for different font and font size combinations.
the constraint to align the center of the two UILabels does not work since the text of the second UILabel is not fixed and can have several lines.
also the text is dynamic, so it is not known where the text will wrap to create the first line, thus it cannot be shown in an one line UILabel with the rest of the text in another one below.
currently this is implemented using UIKit, but if there is an easy solution in SwiftUI we can put these two labels in a SwiftUI component. so a SwiftUI solution would also be welcomed.
Your comments said "it should be on the glyphs" ... but, without additional information, my guess is that "real world" usage would not really need that level of precision.
For example:
While the glyphs are not perfectly center-Y aligned, it seems unlikely you'd run into a case where the first line of the "rightLabel" is " ' " ' " or . , . , ..
This layout can be easily done with only a few constraints - no need to do any calculations:
The "Positioning" label would, of course, be set .hidden = true so it would never be seen.
If you really, really want glyph-precision, you'll need to calculate
the Glyph bounding box for the left-label
the Glyph bounding box for first line of the right-label
calculate the "character box" offsets to align the Glyph Y-centers
and then position the two labels accordingly, or use Core Text to draw the text (instead of using UILabel).
Probably more work than necessary -- unless your actual use-case demands it.
That's an interesting problem! You can try using the centerYAnchor for the label on the left, and the firstBaselineAnchor for the label on the right... that will align the center Y with the text baseline, which isn't quite what you want.
To find the correct offset to apply, you can use the information from UIFont about the size of the characters. I'd probably start with capHeight * 0.5 and see if that looks or feels right. Something like:
leftLabel.centerYAnchor.constraint(equalTo: rightLabel.firstBaseLineAnchor, constant: rightFont.capHeight * 0.5)
This is a more difficult problem in SwiftUI, I think, because resolved font metrics aren't directly available to you.
I'm starting to think is not possible? (out of the box/default class)
I am using FPDF/FPDI PHP class to generate a .pdf
In this situation, I have some text that can be short, or be long (no telling)
So I set a width on my cell.. and change from Cell() to MultiCell()..
This allows long text to wrap.. however it seems to vertically align to the top?
Which is no good if the string is NOT long enough to wrap..
How can you force the text to the bottom of the cell regardless if it is a single line or a wrapped line?
Is there a default way to do this?
I saw mention of TCPDF (or whatever).. and some dead links to 'plug-ins'.. (but not sure if they were FPDI or not?)
This works and looks fine:
$pdf->MultiCell(185, 12, 'ABC-123-DEF-456 And-Last-Name-Here', 1, 'C', false);
However this way, does NOT have the (single line) text at the bottom.. so there is a cap between the string output and the 'underline' it shoudl match up with with (baseline)
$pdf->MultiCell(185, 12, 'ABC-123 DEF-456', 1, 'C', false);
How do you overcome this?
I think, I just found solution.
As default FPDF class I use this code: https://github.com/Setasign/tFPDF/blob/master/tfpdf.php (it supports UTF-8 chars)
Than have edited this class code: http://www.fpdf.org/en/script/script52.php
In Function drawRows() I have changed this row:
$l+=$cw[$c];
To this:
$l+=$this->GetStringWidth($c)/$this->FontSize*1000;
And than use drawTextBox() as is descripted in http://www.fpdf.org/en/script/script52.php
Now I will try to explain:
GetStringWidth() function supports utf-8 chars soo we can use it to calculate char width. And than we can get correct value with some multiplications and divisions for compability with that fpdf class.
I didnt test this code extensivly... only basic testing.
You can do it with a new line, "\n". But you need to keep in mind that cell height needs to be determined by number of "\n", as multi_cell will increase cell height automatically when required.
This is how I have done it:
spacing = " \n\n\n\n\n\n\n\n\n"
contents = "\n" + "hello" + spacing
pdf.multi_cell(10, 3, contents, border=1, align="R")
This will align "hello" to the top right corner.
When creating the spacing I added a space before the \n's otherwise it will be very close to the edge. I also added a \n before the "hello" as otherwise it will be too close to the top. I kept the multi_cell height to 3, but you can even put it to 1 or anything that makes sure your size of \n's is not smaller than the cell height.
I know this is very gimmicky, so if you have a better way please let me know.
This seems could be the answer:
http://www.fpdf.org/en/script/script52.php
Unfortunately, at least to me, it doesn't seem to work when using UTF-8 characters.
I have UITextView, which is left aligned.
When last word does not fit on current line it goes to next line leaving spaces on end of line.
which does not give good look and feel.
So, what I want that if words of particular line feels the spaces left at end.
i.e. Spaces between two words can dynamically varies.
Here I am giving example of Scenario:
The width of text view,never put off until (here tomorrow does not fit,so it goes to next line leaving spaces).
Tomorrow what you can avoid all together.
So, problem is it does look good.
What I want is:
The width of text view never put off, until (varying spaces shown by)
tomorrow -what -you -can
avoid --all -- together.
Thanks in Advance.
There is no setting for justified aligment for text you only have center, left and right. If you want justified aligment where every line has the same amount of characters or something like that you can format the text entered to have carriage returns after x amount of characters or words, or something like that.
Latex seems to fill in white space between the paragraphs by default, to get every page to end at approx the same height (at least with the book and scrreprt class). This is all fine, but I have a couple of pages with only two paragraphs. Latex insists on putting in 2cm of white space between them, which looks bad. I know that I can use \raggedrift for the whole document, but I kind of like the white fill except for the pages with only two paragraphs. I have also tried to adjust manually with \vspace{-1cm}, but it doesn't seem to work.
Is there a way to set a maximum value to the height of white fill between paragraphs?
If your mostly-empty pages are because the following content starts on a new page (at the end of a chapter, for example), then the easiest way to fix it is probably to insert a vertical fill after your last paragraph. The vertical fill should expand to occupy the extra space, keeping the inter-paragraph fill small.
You can change the vertical space applied to every paragraph by setting the value of \parskip.
The solution is very simple. At the end of the last paragraph of the page, add '\vfill'. This will fill up the rest of the page, making the two paragraphs on it move as close to each other as they would normally.
I just tested it myself and it works.
What was the original historical use of the vertical tab character (\v in the C language, ASCII 11)?
Did it ever have a key on a keyboard? How did someone generate it?
Is there any language or system still in use today where the vertical tab character does something interesting and useful?
Vertical tab was used to speed up printer vertical movement. Some printers used special tab belts with various tab spots. This helped align content on forms. VT to header space, fill in header, VT to body area, fill in lines, VT to form footer. Generally it was coded in the program as a character constant. From the keyboard, it would be CTRL-K.
I don't believe anyone would have a reason to use it any more. Most forms are generated in a printer control language like postscript.
#Talvi Wilson noted it used in python '\v'.
print("hello\vworld")
Output:
hello
world
The above output appears to result in the default vertical size being one line. I have tested with perl "\013" and the same output occurs. This could be used to do line feed without a carriage return on devices with convert linefeed to carriage-return + linefeed.
Microsoft Word uses VT as a line separator in order to distinguish it from the normal new line function, which is used as a paragraph separator.
In the medical industry, VT is used as the start of frame character in the MLLP/LLP/HLLP protocols that are used to frame HL-7 data, which has been a standard for medical exchange since the late 80s and is still in wide use.
It was used during the typewriter era to move down a page to the next vertical stop, typically spaced 6 lines apart (much the same way horizontal tabs move along a line by 8 characters).
In modern day settings, the vt is of very little, if any, significance.
The ASCII vertical tab (\x0B)is still used in some databases and file formats as a new line WITHIN a field. For example:
In the .mer file format to allow new lines within a data field,
FileMaker databases can use vertical tabs as a linefeed (see https://support.microsoft.com/en-gb/kb/59096).
I have found that the VT char is used in pptx text boxes at the end of each line shown in the box in oder to adjust the text to the size of the box.
It seems to be automatically generated by powerpoint (not introduced by the user) in order to move the text to the next line and fix the complete text block to the text box. In the example below, in the position of §:
"This is a text §
inside a text box"
A vertical tab was the opposite of a line feed i.e. it went upwards by one line. It had nothing to do with tab positions. If you want to prove this, try it on an RS232 terminal.
similar to R0byn's experience, i was experimenting with a Powerpoint slide presentation and dumped out the main body of text on the slide, finding that all the places where one would typically find carriage return (ASCII 13/0x0d/^M) or line feed/new line (ASCII 10/0x0a/^J) characters, it uses vertical tab (ASCII 11/0x0b/^K) instead, presumably for the exact reason that dan04 described above for Word: to serve as a "newline" while staying within the same paragraph. good question though as i totally thought this character would be as useless as a teletype terminal today.
I believe it's still being used, not sure exactly. There might be even a key combination of it.
As English is written Left to Right, Arabic Right to Left, there are languages in world that are also written top to bottom. In that case a vertical tab might be useful same as the horizontal tab is used for English text.
I tried searching, but couldn't find anything useful yet.