How to identify and separate the one table block to multiple table blocks with C# ?
My idea would be recognizing table headers and logically try and split table blocks. Is there any better way to separate tables ? also, Is there a way to draw new table blocks and regions in a new FRPage with data of existing blocks ?
I would suggest the following way:
Process all pixel lines in your image one by one
In case if there are only white pixels in the certain line, count this line as custom table separator
Divide your page into a few custom analysis blocks by the custom table separators
Call AnalyzeRegion Method of the FRPage Object for each custom analysis block
Call FRPage.Recognize
Related
I’m experiancing a problem when trying to link to tables in the database expert. The two fields that link the tables have exactly the same information except one table always has an additional space. For example;
Table 1 = Multivitamin/Tablets
Table 2 = Multivitamin//Tablets
‘/‘ are representing spaces
Formulas won’t help (e.g. extractstring etc) as it’s the tables themselves I need to link together
This is preventing me from retrieving the information I need. Any advice on how I can get around this?
There are some ways to come across this:
Consider using a command as datasource instead of tables. When writing the query of the command you can define the join condition yourself.
If you have access to the data source, you could add a calculated field to the tables to contain the normalized field values and then use these for linking in CR.
Alternatively, one could create views in the database, either adding normalized "linking fields" or providing the joined tables results.
If it's only a few rows in CR, you could consider using SQL fields or subreports to retrieve data from Table 2.
I have a table built with AG Grid which needs to display different columns depending on the type of data we give it. This is proving slightly difficult, as I can't find a proper interface in AG Grid which allows you setup new columns in existing column groups, and without blowing up user-driven changes (hidden columns, resizing, pinning, etc).
The biggest issue is that I can't figure out how to access column group definitions.
gridOptions.api.getAllColumns()
This function from aggrid does not directly provide column groups, just the child columns. Looping through the columns via this function, they have a parent property, but that does not include the coldef for the column group, which means there isn't even really a way to reconstruct the coldef based on the data you get from it (also, the parent property is private in typescript).
Here is a rough plunker, modified from one of the ag grid documentation examples which illustrates it
https://plnkr.co/edit/C8TrwlkFDg5O5V1RJkng?p=preview
I did try having all the columns present in the table at all times, and hiding them programmatically based on the incoming data, however that creates several issues with the default column show/hide functionality (you can manually show the invalid columns). Using the initial coldefs won't work too well either, since that will discard any modifications the user has made to the columns.
Is there anyone out there who can point me in the right direction?
I implemented a table which bound to a json model.
I want to manipulate it such as one of the column be with various control types depend on the row value.
For example with some condition some rows of same column has text view control and other has dropdown list control.
I attached a sample image:
Thanks in advance!
You could also just create your custom control that renders the control you want based on a property value.
I created a simple example for you: http://jsbin.com/cafumivuco/13/edit?js,output
This has the advantage that only one control is rendered per row and not both while one is invisible.
If i want to insert few rows in the middle of the existing table, how do i approach it? Where all that i should be careful when doing such thing? Is there any good sample source available?
Appreciate your helps.
Thank you.
Tableviews don't contain data and they don't actually contain rows themselves. Instead, tableviews are just an illusion created by redisplaying the same tableviewcell objects over and over again with different data each time. The real table, the real rows, are actually in the logical data.
So, to " insert few rows in the middle of the existing table" you actually add the rows into the data that the table displays. For example, if you had a simple array of names that you display in the table, you would insert the new names into the array. Then you would call -[UITableView reload] which will cause the table to ask the datasource for the new data.
See the Table View Programing Guide for iPhone OS.
Insert the data into your model and call reloadData on the table. If you need to animate the insertion for some reason, you can use insertRowsAtIndexPaths:withRowAnimation:, but the principle if updating the model first still applies.
I am writing code that generates both PDF and RTF documents, depending on the user's selection. The information in both documents is the same.
Until now, we were using classes like Table, Cell, HeaderFooter, etc., which are rendered into the correct form by the documentwriter (either PdfWriter or RtfWriter2).
However, the further I get into trying to make changes (mostly because the upgrade to iText 2.1 left the spacing a little quirky), the more I'm being told to "use PdfpTable", or "Use pageEvents to set headers". It seems like a lot of the generic classes are being deprecated.
I am thinking of revamping the code to separate out the table creations for PDF and RTF. However, all the iText tutorial stuff seems to actually recommend using Table in an instance where both PDF and RTF documents are needed.
Additionally, it appears that while there is a PdfpTable class, there is nothing similar for RTF, so I would be using Table anyway, which would leave me vulnerable to all the quirks that come along with the now unsupported Table class.
Basically, what are the benefits/downsides of separating the code into two sections -- one to create PDF documents, and one to create the same documents in an RTF format, if that was selected? And where does SimpleTable come in to all of this? Will it give me the flexibility that I need?
Thanks!
From the book iText In Action, end of chapter 6:
If you look at the iText API, you’ll also find some other table classes. com.lowagie.text.Table is the original table class; it dates from the early iText days. It uses class com.lowagie.text.pdf.PdfTable internally to render a table to PDF (don’t confuse this class with PdfPTable).
There’s also the newer SimpleTable class, which tries to form a link between
PdfPTable and Table. It’s able to translate itself to a PdfPTable if you add it to a
document that writes PDF or to a Table if you’re producing HTML or RTF. [...]
The major disadvantage of the Table class is that it’s no longer supported. Different
people have fixed most of the known issues, but today not a single person
understands if and how all the Table-methods work. If you decide to use this class,
you’re more or less on your own, and you’ll encounter lots of quirky layout issues
based on historical design decisions. However, this doesn’t mean you can’t make
good use of the Table class.
Advantages of the Table class
With the Table class, you can generate a table structure that can be rendered in
PDF, RTF, and HTML. If you compare the results, you’ll see there are small differences
in the way the table is rendered. This is normal; not every table feature is
supported in every document format.
You can generate a table in PDF, HTML, or RTF using the same code.
You can set padding and spacing the way it’s done in HTML.
You can use the row span without having to resort to nested table.
You can change the number of columns even after you’ve added cells.
You can add cells at specific positions (the number of rows is augmented
dynamically).
You can delete a column before adding the table to the document.
You can let iText add the Table as if it was a PdfPTable.
You get a PdfPTable object based on the Table object.
As opposed to PdfPTable, you can add cells to a Table in a random order, and add
or delete columns if needed. You can even translate a Table to a PdfPTable if you
didn’t use setRowspan().
There’s also the SimpleTable, class, which is a simplified version of (PdfP)-Table. When adding a SimpleTable to a PDF document, iText first attempts to add
the table as a PdfPTable; if this fails, it’s added as a Table. When adding a SimpleTable to an RTF or HTML document, it’s added as a Table. SimpleTable differs
from the Table and PdfPTable in the sense that it reintroduces the concept of rows.
This can be handy if you’re parsing an XML file that has a table-row-cell structure.
If the tag corresponding with the rows has attributes, you don’t have to define this
property for each cell in the row separately; you can set the property for the entire
row at once.
Summary
PdfPTable should be your first choice; but depending on the requirements defined for your project, there can be good reasons to opt for Table or SimpleTable.