(Powerbuilder 11.5.1 build 5097)
I have found that the text size setting (Windows7 Control Panel -> Appearance and Personalization -> Display "Change Text Size") alters printed reports coming from powerbuilder.
When set to smaller - 100% (default), the report works as designed
When set to Medium - %125, 33 rows of data take up nearly one full extra printed line and get cut off.
When set to Large - %150, the report works as designed again.
All my testing is being done with the same computer using the same printer changing just this one widnows preference. The report contains a fixed-size box which takes up most of the right half of the page. When I print using "medium fonts" the bottom of the data gets cut off. Folding over the page and comparing it to a "smaller font" print shows that the report block is exactly the same size but the data within it is drifting downwards.
Call me old fashioned but I firmly believe that the display settings of my monitor should not affect prints. Anyone have any information on how to make powerbuilder behave correctly?
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
I am trying to allow the user to select an appropriate paper size for their printer within my own print settings dialog. Does anyone know a workable solution - preferably cross platform but otherwise OSX.
If I use a TPageSetupDialog then when executed it produces an error in the PASever window of Invalidpmobject although the dialog shows but doesn't seem to affect the current printers paper size. There doesn't seem to be any proerties to see what the user selected either.
I need to set the paper size without actually printing as the user needs to be able to adjust things with the new paper size first.
I finally figured out the problem so here is the solution for anyone else with the problem:
Use TPageSetupDialog but you must set valid pagewidth and pageheight values for the current printer before calling it - otherwise you get an error reported in PAServer window and the printer selection box will be set to "any printer" instead of the current printer name.
Unfortunately you cannot derive the paper size directly from the printer pagewidth and resolution because it reports printable area not paper size. So I set a default of A4 whenever the user chooses another printer. I guess you could set the nearest standard paper size to the calculated value from printer.pagewidth/printer.activeprinter.activedpi.x if you want to take care of printers that do not support A4.
The other point to note is that the default page sizes in the TPageSetupDialog component are wrong. Set the units to mm and use width 210000 and height 297000 (note 10 times bigger than the default values) for A4 size that most printers should support.
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.
Description of Application:
I have an application that allows a user to output a report to a document. The data that is written to the document is in the form of a table. The number of columns in the table and the width of the strings contained in each cell in the table are unknown until runtime (it depends on what query the user runs, what they want to see in the report etc.).
I'm using Delphi XE and Gnostice's eDocEngine to create a PDF document, and then creating a table in the document and writing the report data into it.
Problem:
The problem that I'm having is that you can only write a certain number of columns (6 or 7) into the document before they disappear off the right hand side of the document. It isn't unknown for a user to produce a report with 30 or 40 columns in the table (as they correspond to fields in a database, which they run a query over), so I need to be able to get the table to fit entirely into the document, no matter how many columns it contains.
As a PDF can be zoomed, I suppose I could shrink the font size and column widths down and fit everything in that way, as the user could then zoom in and scroll around the table using their PDF reader. What I need to know is:
Is there a better way of getting the entire table to fit onto a page?
If shrinking/zooming is the best/only way of doing this, what is the most efficient way of ensuring that everything fits without making the document look strange (i.e. the table should ideally stretch across the page, rather than be bunched up to the left hand side because of some random scaling algorithm).
Edit
I've just done some more digging around and I've found "inputXRes" and "inputYRes" properties that change the scale of the canvas in the document, which looks promising, but I can't get it to work properly at the moment. Can anyone shed any light on how those properties are used? The text itself is scaling, but the size of the table stays the same, meaning that I've now got a tiny piece of text in the middle of a huge table cell, and the table is still only displaying 7 columns in the report.
Don't mess with scaling and font size.
Your customers will use PDF Reader and there are some options that will help to read the informations e.g. 1:1. But when you change the scaling or font size you cannot read the information, because it is too small.
Get a font size that fits perfect the needs of your customers and extend the page size to fit the table size.
With PDF Reader your customers will have the choice to view and print (shrink to fit) as they like and which paper size their print can handle.
BTW:
If you change the resolution and draw a line with a length of 2 inch on the canvas it will be 2 inch long, but a text with font size 12 (pixels) will grow or shrink.
I am in progress of converting a really old 25+ year old application .
It sends an escape sequence to make the SCREEN 132 characters wide...
However it didnt work and i put the XTERM equilivment that seems to work in most cases..
It is
"\x1B[8;50;132t"
Although the screen resizes with success there is an issue
Here is the code that the COBOL program uses to execute the command
pg -f FILETOSHOW
using CALL "SYSTEM" USING BY CONTENT DS-REC
where DS-REC is the above command....
The problem is that although screen resizes data are printed with the previous settings... Calling again the program solves the issue and prints correctly...
Doesnt anybody knows whether i should send another escape code also?
The escape sequence is documented in XTerm Control Sequences, in the "Functions using CSI , ordered by the final character(s)" section, under this line:
CSI Ps ; Ps ; Ps t
It is one of the controls adapted from dtterm, and in particular
Ps = 8 ; height ; width
Resize the text area to given
height and width in characters. Omitted parameters reuse the
current height or width. Zero parameters use the display's
height or width.
It was implemented in xterm in 1996 (patch #18).
Because some users view operations of this sort as a security problem (including resizing the font), a resource windowOps was added in 2003 (patch #174) to allow packagers to change the default behavior. That resource can be modified at runtime using a menu entry, as well as set directly in a user's X resources.
In short, the feature is present in xterm, but may require (simple) configuration changes to use it.
The control sequence to resize the xterm window is a request to the window manager. The window manager may not honor the request, e.g., for tiling window managers it would always fail. Also, because xterm does not change the font-size dynamically, it may fail if the font size is too large to permit 132 columns on the screen. The fixed font probably works for modern large displays (my 1280x1024 monitor can display 60x210 with some slack), but large fonts may not.
When it fails to resize as large as requested, it is the window manager which handles the request: xterm has forgotten by the time the request is completed, and will accept whatever the window manager does.
Do not rely on these escape codes. xterm will not set itself to a size greater than the screen. So given the user has a large-enough font and/or a small-enough screen, he will not get his 132x50 terminal automatically, much less will the automatic sizing do it.
(E.g. lucida console at 15pt on 1024x600 minus a taskbar and WM deco gives me room for 85x28 cells.)
If your program requires such an awkward vt size of 132x50, request it of the user as a prerequisite. Or just make your program actually run on any variable size.