I am working in an SSRS report that is intended to print MICR checks, I am using the MICR E13B M2 font with a font size of 13pt, and the MICR line printed fit the gauge spots properly most of the times, however I am having a problem among several printings, every time I print a check the start position of the MICR line is not the same as in the previous printing, it moves a little. This is causing that many of the times my checks don’t meet the specifications of where every MICR line character must be placed. I am using an HP LaserJet M203dw printer with magnetic ink. I don’t have many experience with MICR checks and I haven’t been able to find a similar problem, do anyone has had a similar problem? I would appreciate any idea to troubleshot the issue.
Valentin, does the line move vertically or horizontally?
If the line is moving vertically, you must have a MICR print settings to X, Y locations in your software. Also you need to see if the printer paper stacker is holding the paper tightly and papers in it should not be lose.
Related
I am using tesseract 3.05 for reasons beyond my control. I am using source files to train the engine to detect this unique font. As I have a vast amount of samples, I am simply using the samples themselves as the training images rather than segment them into a font training image as this should give it more variation and training with the specific spacing issues this font has.
My question when generating the box files, as some letters are touching at corners (i.e . no clear break between glyphs), it will detect them as one glyph instead of two separate glyphs. An example it sometimes struggles with NA as the front serif of the A has bled into serif of the N. The image pre-processing I have applied has improved it by leaps and bounds but there are still some that I cannot correct on the image enough.
My question is this: can I simply denote the glyph as being NA in the box file?
If I cannot what would be the simplest solution? Introducing another glyph box seems like it wouldn't be a good idea but the only other solution I can see is to manually edit the image to make the separation of glyphs more obvious. This is itself anthi-thetical however as this is the kind of problem the font will have in the future that I am trying to OCR.
Thank you in advance but the documentation isn't specific on if I can correct a box glyph to being two characters instead of just one (or I just haven't found a relevant section where they explain this).
After scouring the documentation, I managed to find a lone paragraph that wasn't appearing in my website scraping:
"If you didn't successfully space out the characters on the training image, some may have been joined into a single box. In this case, you can either remake the images with better spacing and start again, or if the pair is common, put both characters at the start of the line, leaving the bounding box to represent them both. (As of 3.00, there is a limit of 24 bytes for the description of a "character". This will allow you between 6 and 24 unicodes to describe the character, depending on where your codes sit in the unicode set. If anyone hits this limit, please file an issue describing your situation.)"
Thus you can do what I ask: represent a glyph with two or more characters in a box file for Tesseract.
I use report with textbox (in Access 07) that should resize with length of text. I use the 'can resize' and 'can shrink' attributes. This mostly works, but on some computers the text box stay in 'original' size, as it appears on design view of the report.
I didn't find what could cause this, all computers have the same version of office (07), reinstalling office doesn't change anything?
So onto the questions. Any ideas how to avoid this?
Is there a way to adjust the size (height) of the textbox in report through access. Is there a way to determine the number of lines a text will take in some font and size other then dividing length of the string (using rich text) with some predetermined number.
Can you check the problem user's profile to make sure they have a printer installed?
I know it sounds like a silly answer, but I've seen odd things happen in Access Reports when no default printer is defined
After a Citrix upgrade, all my MS Access reports appear slightly bigger and several of them bleed over the margins into additional pages where a sliver hangs over.
It is not feasible for me to go through each report and manually resize everything in Design View -- several of them have already been compressed quite tightly. Is there no way to "fit to width"?
There is indeed a "Fit to Page" property.
Report properties -> Format Tab -> Fit to Page -> Yes
It is in my experience that I'm going to say that this probably won't be the universal fix you're looking for, and it might not even work. On reports that have bled over, I had to manually adjust each report. Of course I noticed this as I was developing them so it was not as time-consuming if I had to do 20 within a week, per se.
There are a decent amount of properties you can toy with, including Page Width, Auto Center, Auto Resize, etc.
Formatting can get very tedious. I'm hoping the default properties will work for you, but keep in mind that a manual fix may be required.
I believe your problem is related to the printer driver. Microsoft Access reports are constrained by the capabilities (printable area) of the printer driver assigned to them (either the default printer, or a specific printer, if chosen).
The unprintable margins of your printer, as defined by your printer driver affect how your Access report pages will be laid out when previewing or printing.
For example, if you have your default printer driver set to a laser printer, you can usually design a report with 0.25 inch margins on all four sides (top, bottom, left right). For this example, lets design a report that fills the page with 0.25 inch margins, and only takes one page.
Then, if you change your default printer to an inkjet and open the same report, you may find that the report is now wider and/or longer than one page. The reason is that in many cases, an inkjet printer has wider minimum left and right and/or top and bottom margins. Some inkjet printers can't print closer than 0.6 inches from the bottom of the page. So, your report which fit with 0.25 inch margins now is wider or taller than one page because the printer driver settings will take precedence over your report margins.
Unfortunately, with Microsoft Access, there is not a true "fit to page" feature, like Excel. I wish there were.
I would imagine that your printer driver has possibly been changed or upgraded and now has a narrower printable width. (i.e. previously the minimum left and right margins were 0.20 and now the minimum left and right margins are 0.25)
If you open a report in design view, then go to the Page Setup, set all of the margins to 0. As you type the "0" and exit each field, you will see Access change the 0 inch margin to the minimum allowed value for the current printer.
Unfortunately, the best advice I can give you is to design your reports with the margins of your "least capable" printer. The safest margins are usually no less than 0.3 inches for left and right, and no less than 0.5 inches top, and 0.6 inches bottom (to accommodate most inkjet printers).
You will probably have to manually edit each report in design view in order to fix them, OR change the printer driver.
I noticed that nobody addressed that your project is using MS Access on Citrix which is essentially a remote connection to a computer that users share (aka Terminal Server). As I recall there are special Office installation files that are required when installing Office on a terminal server. In part, the installer addresses how video and print drivers are used. I found this to apply to both displaying Forms and printing Reports. For Forms, in the end I had to apply finishing layout touches via the remote connection so that the video drivers metrics were saved with the form. For reports, there were two issues: The first is making sure that each report is set to use the 'Default Printer'. There is code available to walk the reports and set each to the Default Printer. The second was again finalizing each report's layout using the remote connection and the default printer installed on the remote connection. However the workaround to this is to install an local generic printer driver (aka an basic Epson Dot Matrix driver) and final each report for that printer. When deployed most modern printers understand the metrics of the basic printer driver. Note that code could be used to walk the list of reports, open in design mode, change a setting and the Default Printer then save. This could be enough to reset each report's configuration to match a Citrix or Terminal Server deployment.
I hope this helps!
Ken
Developing MS Access custom applications since Version 1.0 - Our first version had a box's serial number of 0000071 which we acquired as a give-away during the launch at Comdex Las Vegas.
The TortoiseHg Commit window has a thin vertical red line in the text area where you can write your commit message:
What is the purpose and/or meaning of this line? The relevant TortoiseHg documentation comes up empty. Searching Google and Stack Overflow currently give zero results.
Is it a suggested(?) or recommended(?) place to put hard line breaks in commit messages? If so: why have such a suggestion at all, and why at that particular location?
Okay, bro, it 's your personal hand-made settings (default value - unspecified)!!!
TortoiseHG - Settings - Commit
and at the bottom, when this listbox is active, you can read description and purpose of this parameter
Without knowing this platform I would say it's a text wrap marker - where text would wrap when printed as pure text to a printer. the old "standard" had a width of 80 chars (72 on some platforms) for ASCII-based documents.
The width was also relevant to pure-text document viewers who typically wrapped text at 72 or 80 chars. It was also used for terminals at the time when BBS'es was the norm (before internet became popular).
I suspect the reason is to provide backward-compatibility to the more old-school developers who might want to read this in a plain text reader and for printing (printing pure text is many times faster than formatted text which is printed as graphics, and therefor convenient when printing documentation and so forth). But this will be just a guess on my part.
I have some pre-printed A4 papers and I want to print some data on them on specific locations on the paper (think of it as a form with boxes which must be completed). I 've tried to do it with html and css and i 've managed to display the data correctly on the printed paper with my configuration (specific margins, printer, etc).
My hesitation is if the browser, the printer, the printer driver (or some other parameter) affect the way the data are printed in a way that I won't get the right result.
Is it feasible to use html and css for accurate printing? If the answer is yes how would you do it? (My approach is using relative positioned divs for each page with absolute positioned divs for every box of the form)
If the answer is no what would propose alternatively? (maybe html and use of table tags? something else completely different?)
I would do it in PDF or Flash. Very similar to the way www.stamps.com do when you need to print stamps.
Reason for those two technologies is they are really cross platform and give same results on all systems.