I have a document in MS Word 2010 that contains several textboxes. The document looks completely fine in print preview; however, when printed the texboxes shift position. The strange thing is I've tried printing the document on another printer and it works just fine. It also works if I try to print it from Word 2007. I ran the compatability checker in Word and it came back with the following message: "Some text box positioning will change".
Anyone have a clue what's going on here?
According to this site, the message appears due to the following:
In text boxes, text that is centered vertically or aligned to the
bottom will be permanently aligned to the top even if you later
convert the document to Office Word 2007 format.
This site has similar text
In text boxes, text that is centered vertically or aligned to the
bottom will be permanently aligned to the top even if you later
convert the document to Word 2010 format.
Either way, if a different printer attached to the same system prints it correctly then you will want to see if the printer that fails has an updated (or alternate) print driver.
I had a similar problem when printing a .doc file in Word for Mac 2011. I saved it as a .docx file instead, and that fixed it!
Related
fist off, if there is an exchange place more suitable for the question, please address me.
I'm designing some labels in gimp.
I created a A4 300dpi document and created the artwork, arranged them to use all the page. To measure the labels I create a rectangle with the "rectangle selection tool" and there one can inspect the size in cm:
I printed straight from gimp and to my surprise, the printed labels where smaller than designed. I assumed somehow someone along the line added margins to my already A4 document..
I tried saving to PDF and then printing the PDF, very similar results.
I'd say the difference is around 5%
What would be the appropriated method for printing exactly at the size I created the document ignoring any margins ??
I'm using Windows 10, HP ENVY 5010 and Gimp 2.10
Is it possible to enter from keyboard special Unicode characters, link the ones below?
U+2603 ☃ SNOWMAN
U+2604 ☄ COMET
U+2605 ★ BLACK STAR
U+2606 ☆ WHITE STAR
U+2607 ☇ LIGHTNING
U+2608 ☈ THUNDERSTORM
U+2609 ☉ SUN
U+260A ☊ ASCENDING NODE
U+260B ☋ DESCENDING NODE
I would like for example to have buttons with up/down arrows in them, without loading images.
I have tried entering Alt+08593 on keyboard but other character (than the expected arrow) will be inserted.
Update:
The reason for this is LAZINESS. I am too lazy to search for icons or create my own icons. For example you can simply replace the notorious 'save' floppy disk icon. Just take a look at: 💾. BAM! Nice. Right?
Update:
It seems some characters such as 📗 (green book = 128215) are not accepted by Delphi, with copy/paste.
Update:
There is nice component that allows you to put unicode chanracters in a image list:
https://github.com/EtheaDev/IconFontsImageList
The Delphi IDE won't accept ALT key codes that high. A couple of alternatives:
Paste the text from somewhere else.
Enter the numeric code directly in the .dfm file.
As an example of the second approach, try this in your .dfm file for the button caption property:
Caption = #8592#8593#8594#8595
You also mention Green Book U+1F4D7. That is from outside the BMP, and hence encoded with a surrogate pair:
Caption = #55357#56535
My guess is that as soon as you want your glyphs to be shown in colour, or at a different size, you will find that using text makes this impossible. You are also likely to encounter fonts that don't contain glyphs for the characters you select. So you will find that using images is the most robust approach.
Or, alternatively, if you had a table of the decimal values:
9731 ☃ SNOWMAN
9732 ☄ COMET
9733 ★ BLACK STAR
9734 ☆ WHITE STAR
9735 ☇ LIGHTNING
9736 ☈ THUNDERSTORM
9737 ☉ SUN
9738 ☊ ASCENDING NODE
9739 ☋ DESCENDING NODE
then you can use the keyboard as follows in Delphi.
To change the caption of Button1 to be the snowman:
Press Alt+F12 to edit the form as text
Press Ctrl+E to enter incremental search mode
Type Button1, or as much of it as is required to locate the definition of Button1
To the right of the Caption = property definition (I'm assuming VCL here) enter # followed by the relevant Unicode value, e.g. #9731
Caption = #9731
If you want text as well as the snowman, the character code goes outside quotes, so e.g.
Caption = 'Snowman = '#9731
More info on the # syntax (which is more commonly entered in Delphi source, rather than in the text view of form files) can be found by reading about control strings, as they are actually called, in the online documentation.
We have a very old program that we print from where you are unable to change the left print margin in the program. I need to get it printing further from the left edge, ideally about 1 inch for binding. No issue with text going over the right edge as it doesn't get near that side of the page.
My idea was to use a custom separator page https://support.microsoft.com/en-us/kb/131714 to issue a PCL command to increase the left margin.
We are using HP printers and I have tried using the standard windows example C:\Windows\System32\pcl.sep which works exactly as expected.
This is my attempt at a .sep file (am saving in the system32 folder)
\
\H1B\L%-12345X
\H1B\LE
\H1B\L&l4000U
\H1B\L&a+3000H
\
I've tried a couple of variations, but it does absolutely nothing, my document just prints like normal.
Any help much appreciated.
My guess is that the application is explicitly setting the margins,
thus undoing anything you are trying in the .sep file. I am not familiar with the .sep file at all.
In the PCL context, if you are printing in duplex you want the extra binding on the left for the front side and on the right for the backside. The PCL command to end up with a 1 inch binding margin would be something like &l540U The 540U shifts the image 3/4 inch which when added to the existing minimum 1/4 inch margin gives you a 1 inch total.
Can you direct your output to a file to see what is actually being sent to the printer?
I'm using PHP to generate docx documents from a database. The generated document contains column charts which have labels attached (i.e. user shapes containing textboxes). In an attempt to get the textboxes to accommodate and display all of the text (i.e. it shouldn't be necessary for the user to resize a textbox to see all the text) my code calculates how many characters will fit into 3cm, adds linefeeds to the string as required and tells me how many lines of text are needed. I have:
<a:xfrm xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main">
<a:off x="1638276" y="1676399"/>
<a:ext cx="1257325" cy="'.(252000 * $labelLeftLines).'"/>
</a:xfrm>
which I believe should give me a text box around 3.5cm wide (extra .5 for the internal padding) and a height of .7cm multiplied by whatever is the value of $labelLeftLines. However, the text box always turns up as 3.cm wide by .86cm high, which only ever displays one line of text.
If I add in 'autofit':
<a:bodyPr xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" vertOverflow="clip" wrap="square" rtlCol="0">
<a:spAutoFit/>
</a:bodyPr>
the generated file looks just the same, though, when I right click on the textbox to inspect the properties, 'autofit' is indeed applied. I have to uncheck it and recheck it to make it affect the textbox.
Any openXML gurus out there?
Hmm, some random floundering around revealed that the values I need to manipulate are here:
<cdr:relSizeAnchor xmlns:cdr="http://schemas.openxmlformats.org/drawingml/2006/chartDrawing">
<cdr:from>
<cdr:x>0.47</cdr:x>
<cdr:y>0.75</cdr:y>
</cdr:from>
<cdr:to>
<cdr:x>0.67</cdr:x>
<cdr:y>1</cdr:y>
</cdr:to>
Changing those values does actually change the size of the texbox, though I haven't a clue what units are being used. From 0.75 to 1 produces a height of 1.43cm.
One day I'll maybe be able to find my way around the doucmentation.
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.