When i type 1960 characters in CKEditor and submit the form, my controller is getting around 2000 characters. I have checked through the data but still cant find out the exact reason why it is going like that
Length of data in UI : 1978
Length of data in Controller : 1991
so, additional 13 characters are added.
The data i am sending in UI is as follows --------------------------------------
Some older driver versions allowed you to select the “letter” size and adjust the margins to define the ticket size. This feature is still available in the new drivers to support old installations. When selecting a new font, Windows will default to the previous font size. This size will usually be incorrect. You must re-assign a valid font size to guarantee the proper font representation on your screen. "Tall" font in Word Pad does not display properly on the screen. Driver Use – Word Only (PCL and FGL) Before using Word, you must select the “use printer metrics to layout document” box in tools/options/compatibility. All of the previous “driver use” guidelines apply to Word. Word also provides you with the unique ability to define a custom page size within the application itself. We strongly recommend against the use of this feature. However, the following description will explain the use and limitations of this feature. While Word allows you to manipulate the page size in both portrait and landscape modes, the data sent to the printer only functions properly in portrait mode. You cannot print in landscape mode with a Word defined custom page size. In portrait mode, you can manually set the height for any ticket length up to 11 inches. For ticket lengths greater than 11 inches, you will need to add your own page size as described above in the “all applications” section. lengths greater than 11 inches, you will need to add your own page size as described above in the “all applications” section. lengths greater than 11 inches, you will need to add your own page size as described above in the “all applications” section. lengths greater than **
The data im receiving in controller is as follows --------------------------------------
Some older driver versions allowed you to select the “letter” size and adjust the margins to define the ticket size. This feature is still available in the new drivers to support old installations.
When selecting a new font, Windows will default to the previous font size. This size will usually be incorrect. You must re-assign a valid font size to guarantee the proper font representation on your screen. "Tall" font in Word Pad does not display properly on the screen.
Driver Use – Word Only (PCL and FGL)
Before using Word, you must select the “use printer metrics to layout document” box in tools/options/compatibility. All of the previous “driver use” guidelines apply to Word. Word also provides you with the unique ability to define a custom page size within the application itself. We strongly recommend against the use of this feature. However, the following description will explain the use and limitations of this feature.
While Word allows you to manipulate the page size in both portrait and landscape modes, the data sent to the printer only functions properly in portrait mode. You cannot print in landscape mode with a Word defined custom page size.
In portrait mode, you can manually set the height for any ticket length up to 11 inches. For ticket lengths greater than 11 inches, you will need to add your own page size as described above in the “all applications” section.
lengths greater than 11 inches, you will need to add your own page size as described above in the “all applications” section.
lengths greater than 11 inches, you will need to add your own page size as described above in the “all applications” section.
lengths greater than
I depends on the way you are requesting the output, but this can be spaces or this could also be some \n\r tags for all the that you have inserted.
Did you try already to see the differences in short texts, to find you what it is exactly?
I think it are some \n\r tags, you should see these tags when you request the data in you code.. If not i'm sure it are spaces.
Related
I am using telerik reports. Some of my reports are large sized. When printing these reports not fit into default page size. I need to fit it into page by default. How can I implement this? Pls reply
Each report has a defined size in its definition which you can change and the same goes for page margins. You should also have in mind that each printer has hardware margins which is not possible to override. With that taken into account, you should be able to set an appropriate size that prints correctly. If still in dilema, elaborate on the report size, its pagesettings and the printer and paper format you're trying to print to.
I have a SSRS RDL that is formated to fit on a three column lable sheet. When exported to PDF the 2nd column is not populated and on the next page the 2nd column is the only column populated. This continues to happen for as much data as I have. Has anyone had any problems with this or might have an idea on where the problem might be?
These kinds of quirks are usually related to the margins. Make sure that the actual label area does not exceed the page size, accounting for the margins. Also, printer drivers can cause a similar issue because of content-to-page-size issues, where the report shows correct on-screen but when printing, shifts content to a new page.
This is because of page setup properties. For example if a page is set to letter size(8.5in X 11in) and left and right margins to 1 inch. then you have adjust you report body size to 6.5 inch or below, if it exceeds above 6.5 inch, then leads to split data to other pages when exported to PDF.
After inspecting the information of individual fields attached to the doc.Form I see the expected font settings. However, once Stamp() is called and the PDF rendering completes the font size is not retained, although the font itself and some relative sizing is.
Versions: 7 and 8
Additionally, despite having :
doc.Form.NeedAppearances
doc.Form.GenerateAppearances
doc.Form.FormatFields
set true, the system appears to ignore Adobe JavaScript such as:
getField('MyField').textSize = 12
Should anyone else encounter this error, you should start by checking the size of the fields on the PDF you are filling. If the field sizes are not deemed large enough to hold your selected font then ABCPDF scales the font to a size of its choosing. Once the fields are large enough to contain the font, by ABC's standards, then the font size will be limited by the settings you choose. In this case you should oversize your fields whenever possible.
This picture illustrates my predicament:
All of the characters appear to be the same size, but the space between them is different when presented in a RichEdit control compared with when I use ExtTextOut.
I would like to present the characters the same as in the RichEdit control (ideally), in order to preserve wrap positions.
Can anyone tell me:
a) Which is the more correct representation?
b) Why the RichEdit control displays the text with no gaps between the Asian Characters?
c) Is there any way to make ExtTextOut reproduce the behaviour of the RichEdit control when drawing these characters?
d) Would this be any different if I was working on an Asian version of Windows?
Perhaps I'm being optimistic, but if anyone has any hints to offer, I'd be very interested to hear.
In case it helps:
Here's my text:
快的棕色狐狸跳在懶惰狗1 2 3 4 5 6 7 8 9 0
apologies to Asian readers, this is merely for testing our Unicode implemetation and I don't even know what language the characters are taken from, let alone whether they mean anything
In order to view the effect by pasting these characters into a RichEdit control (eg. Wordpad), you may find you have to swipe them and set the font to 'Arial'.
The rich text that I obtain is:
{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\fs22\u24555?\u30340?\u26837?\u33394?\u29392?\u29432?\u36339?\u22312?\u25078?\u24816?\u29399?1 2 3 4 5 6 7 8 9 0\par\pard\'a3 $$ \'80\'80\cf1\lang2057\fs16\par}
It doesn't appear to contain a value for character 'pitch' which was my first thought.
I don't know the answer, but there are several things to suspect:
There are several versions of the rich edit control. Perhaps you're using an older one that doesn't have all the latest typographic improvements.
There are many styles and flags that affect the behavior of a rich editcontrol, so you might want to explore which ones are set and what they do. For example, look at EM_GETEDITSTYLE.
Many Asian fonts come in two versions on Windows. One is optimized for horizontal layout, and the other for vertical layout. That latter usually has the same name, but has # prepended to it. Perhaps you are using the wrong one in the rich edit control.
UPDATE: By messing around with Wordpad, I was able to reproduce the problem with the crowded text in the rich edit control.
Open a new document in Wordpad on Windows 7. Note that the selected font is Calibri.
Paste the sample text into the document.
Text appears correct, but Wordpad changed the font to SimSun.
Select the text and change the font back to Calibri or Arial.
The text will now be overcrowded, very similar to your example. Thus it appears the fundamental problem is with font linking and fallback. ExtTextOut is probably selecting an appropriate font for the script automatically. Your challenge is to figure out how to identify the right font for the script and set that font in the rich edit control.
This will only help with part of your problem, but there is a way to draw text to a DC that will look exactly the same as it does with RichEdit: what's called the windowless RichEdit control. It not exactly easy to use: I wrote a CodeProject article on it a few years back. I used this to solve the problem of a scrollable display of blocks of text, each one of which can be edited by clicking on it: the normal drawing is done with the windowless RichEdit, and the editing by showing a "real" RichEdit control on the top of it.
That would at least get you the text looking the same in both cases, though unfortunately both cases would show too little character spacing.
One further thought: if you could rely on Microsoft Office being installed, you could also try later versions of RichEdit that come with office. There's more about these on Murray Sargent's blog, as well as some interesting articles on font binding that might also help.
ExtTextOut allows you to specify the logical spacing between records. It has the parameter lpDx which is a const pointer to an array of values that indicate the distance between origins of adjacent character cells. The Microsoft API documentation notes that if you don't set it, then it sets it's own default spacing. I would have to say that's why ExtTextOut is working fine.
In particular, when you construct a EMR_EXTTEXTOUTW record in EMF, it populates an EMR_TEXT structure with this DX array - which looking at one of your comments, allowed the RichEdit to insert the EMF with the information contained in the record, whereby if you didn't set a font binding then the RTF record does some matching to work out what font to use.
In terms of the RichEdit control, the following article might be useful:
Use Font Binding in a Rich Edit Control
After character sets are assigned, Rich Edit scans the text around the
insertion point forward and backward to find the nearest fonts that
have been used for the character sets. If no font is found for a
character set, Rich Edit uses the font chosen by the client for that
character set. If the client hasn't specified a font for the character
set, Rich Edit uses the default font for that character set. If the
client wants some other font, the client can always change it, but
this approach will work most of the time. The current default font
choices are based on the following table. Note that the default fonts
are set per-process, and there are separate lists for UI usage and for
non-UI usage.
If you haven't set the characterset, then it further explains that it falls back to ANSI_CHARSET. However, it's most definitely a lot more complicated than that, as that blog article by Murray Sargent (a programmer at Microsoft) shows.
So I've recently had to create a report that emulates a Canadian customs form. The problem is that the report is printed on 11" x 14" paper, but uses a metric layout. As my FoxPro installation is on a machine with US-English units-of-measure, FoxPro tries to oblige by using an English ruler, and doing snap-to-grid on inch-based measurements. This creates some minor design issues obviously.
I understand that the reports are really just tables in disguise, and I have figured out how to turn on the Metric ruler (instead of the English one) by changing a record, and that is working as intended. However, the snap-to-grid functionality appears to want to snap on 48 units-to-an-inch, instead of something Metric. So moving a box around using a mouse results in the box being offset (again) in English measurements.
To get around this, I have taken to openning up the report as a table and manually converted all Metric units with a spreadsheet, and entered the offsets and sizes by hand. While this has worked well and appears to be very accurate, it's still error-prone.
So the question is, how do I get FoxPro 8 to snap-to-grid in Metric units on the report, so that I don't have to keep re-entering numbers by hand? It would be nice to get FoxPro to accomodate Metric in a fashion where I can align objects in the report using a mouse, rather than punching them in as numbers and "flipping" the report into design view to check it.
For reference, currently there are the following translations:
25.4 mm = 1 inch = 10,000 report units = 48 grid snap points
Obviously I'd like something closer to this:
25.4 mm = 1 inch = 10,000 report units = 25.4 grid snap points
Note: Yes, I have considered setting up a Virutal Machine with FoxPro that uses a Metric install, i.e. a Windows XP install set up for Canada. However, that will take another day or so to get the installation done, along with the rest of the development environment, so I'm trying to avoid that.
Hidden unless you've been exposed to more of it...
Modify your report.
Right-click, get to properties of the report.
On the tab for Ruler / Grid, there is a combobox which is defaulted to ruler of "inches", but you can change it to Metric/cm or Pixels. Below that is your grid snap and you can change the default of how many pixels to snap to.
Additionally, if you use your cursor keys, you can move the controls one pixel at a time for more precise alignments as needed. And if you need to resize a control's width, if you hold the Ctrl key down and use the arrow keys left/right, will shrink / strecth one pixel at a time instead of moving the control. Likewise for the moving and sizing if you pick multiple controls, they will ALL move or resize respectively.
HTH
Just spoke with a freind lastnight who has VFP8 installed. Based on that version, there MIGHT be a way to get metric for your reports. There is a setting on the reports from showing based on PIXELS, or SYSTEM METRIC. If you system configuration is based on inches, so too is the report. If you change your system metric to that of centimeters (or whatever equivalent it would be), so too should the report respect in design time.
HTH