I'm trying to make a document comparison viewer for web browser that feels as same as Microsoft word's 'Track Changes' and 'Compare' (options available in Review Tab).
I am already using Aspose.Words to convert every file type to docx and compare two files which gives me a redline copy merged into one single document. What i want to get is the resulting document(s) in a side by side comparison on UI. Also i want to give the ability to do the basic:
Get a summary of changes made and able to navigate as to where to changes are made in the document.(Scroll to the position of change in the document, just like Review Pane in MS word)
Accept and Reject those changes and download the revised document.
Able to compare text as well as non text related changes.
I've looked for many 3rd party tools but always end up in a limitation surrounding them, to list a few
GroupDocs.Comparison - Gives navigation and auto scroll but in a
merged document not in side by side view. Also, does not gives a document but a set of images.
Draftable - Compares only text and style, no image/tagged file
objection insertion or deletion. No option to accept or reject
changes
ipdf-net - No option to accept or reject changes.
PrizmDocs Document Compare API - No navigation to where the change is made in the document. Also no side by side comparison.
Litera Compare: No side by side comparison.
Where i could such 3rd party SDK that would help me achieve my objective or is there any was i could overcome the limitations i am getting from the tolls I've looked at ? The main concern is to have a navigation/mapping of change made to its position in the document and ability accept or reject those changes.
GroupDocs.Comparison provides following features:
Accept or reject detected changes
Get comparison summary page
Get list of changes
Get changes coordinates
Customize style changes
Adjust comparison sensitivity
Text and image comparison
Learn more about all the supported features in developer guide. We are also investigating the possibility to implement side by side comparison of the documents. You'll be notified as there's any progress update.
Related
Does anyone know what ZCD may refer to? It is described as a segment with a link back to PreManage for the patient!
Can anyone please provide more details?
The Z segments (segments those begin with the letter "Z") are custom segments. Those are not defined in specifications. They vary from vendor to vendor. Vendor may publish a document explaining usage of segment. Two connected parties should know in advance and decide the usage by mutual understanding.
As those are custom, and if there is no way to know what data they contain, it may be safe to neglect them hoping the sender have not put critical data in it.
Please refer to this:
Z-segments can be inserted anywhere in the HL7 message. A popular approach is to place the Z-segment within a group of segments that contain similar information, such as insurance. Z-segments are also often placed at the end of the message. The advantage of doing so is that this placement prevents systems configured to parse “standard” HL7 format from requiring any configuration modifications in order to process the message. The application simply reads the segments in the order expected and then extracts the data from the Z-segment (if needed) via parser modifications.
Working with unexpected Z-segments
Sometimes systems may send unexpected Z-segments, whether or not they were part of the original specifications. Even if you are not interested in the data in the Z-segment, you may still (depending on its location) need to take the segment into account while testing and developing your interface.
I want – as the title says – extract programmatically a shape from a Draw document through the api interface. Beside I want to import such a shape into a document as well.
I saw some predefined shapes in XML form and the document is stored as XML structure as well. Is there a known way to anybody out there to allow the storage and load of one shape?
What is this good for?
I want to, for example, enable the programmatic deletion of objects. But to enable the undo/redo functionalities I need to “store” the deleted shape. Beyond that this would allow me to add user-defined objects programmatically, e.g. arrow heads, UML structures or unicorns.
Thanks in advance for any ideas,
J
P.S.: I work with LibreOffice Version: 5.2.1.2 . Access the interface through C# (so java and C++ would do it as well) but any ideas are welcome.
I'm not entirely sure what you are trying to do, but here are some ideas:
Instead of deleting an XShape, you could use the dispatcher to Cut it. That will store it in the clipboard, so if it needs to be added back then the dispatcher can Paste it, as long as no other copy or cut was performed.
To create a shape, see the example at https://wiki.openoffice.org/wiki/Documentation/DevGuide/Drawings/Shapes. This code will look different depending on what kind of shape it is. It sounds like you are asking for one code listing that will programmatically create any type of shape, but I do not think it is that easy.
Instead of using the UNO API, you could programmatically modify the XML files, which may make it easier to store and work with any shape. Be sure to use an XML parsing library, not just regular expressions.
I've read about the ePub format, standard, structure, readers, tools and available developer techniques to manipulate/convert/create ePubs but there is no such thing as a magical function (so far) to extract a particular length of characters to create an excerpt of the book. And that's precisely what I'm looking for: A way to extract the first X words of an ePub.
The first approach I'm considering (not my favorite btw) is creating a parser to read all the ePub metadata and start parsing the xml files in the right order until I have enough words to create the excerpt of a determined ePub (I will appreciate some feedback in this direction)
The second way (which I can't find so far) is an existent tool/function or parser (in any language) which returns (hopefully) the plain text of the ePub so I can collect the first X words in order to create my excerpt.
Do you know about any tool which can help me achieve the second option?
You should have a look at Apache Tika: http://tika.apache.org/
You can use it from command line, or as a java library or even in server mode to extract text from ePub.
Hope this will help,
F.
Jose,
I'm not aware of any tool to do what you want. Let me comment on your first approach, though. If you do find a tool I hope these comments allow you to evaluate it.
I think your approach is fine and, if you want to do a good job of creating an extract, you may want to own this step anyway. I would suggest you,
grab the OPF file and look for a GUIDE section. If a GUIDE section exists, check the types that are given. Some are probably not relevant for an excerpt (cover,title-page,copyright-page). Many books will not have the types explicitly stated but this should help where they do.
now go through the files in sequence in the SPINE section, excluding anything that is irrelevant, and read through enough XHTML files to get your excerpt.
while in the OPF file grab a bunch of metadata if this is relevant for the excerpt (title, creator, date are mandatory, I think, and some authors will also put in a whole bunch of other metadata such as keywords).
If you are creating a mini-EPUB with this excerpt you will need to pick up any CSS, Audio, Video, Image and Custom Font files that get referenced in the XHTML files used to make your excerpt. You may even choose to use the original cover file for the cover file of your excerpt epub.
If you working with fixed layout books with fun stuff like Read Aloud AND you want to create a mini-EPUB as an excerpt, you may be better off going with a page count rather than a word count. Don't forget to include any SMIL files into your excerpt and to make it look nice: (i) don't split a two page spread and (ii) make sure that the first page is an odd numbered page if odd in the original or even if even numbered in the original - to do this you may need to add a blank filler page (get the odd/even wrong and subsequent two page spreads won't be facing each other)
I hope that helps.
I'm working on the requirements & specifications for a new iOS app intended for use by certain professionals working "in the field". All day long for weeks on end, these folks have a sizable reporting burden to their superiors using standardized forms that track all different kinds of information. Traditionally, those forms are in PDF, and are simply printed and filled out in ink and then shared with the dozens to hundreds of others working the same operation. Sometimes they'll use a PDF with form fields so the data can be typed and then printed as part of the form. Either way, given their workflow, time and stress pressures, and other factors, it's not a very productive way to get the standardized reporting forms done.
The app we're spec'ing would offer an iOS (and Android, if possible -- but secondary or even tertiary requirement at this point) user interface for tracking the data they enter in the field, organizing it in a logical manner for each individual user, and with the press of a button, take all that data and automatically create a PDF file of it using the standardized form.
Of course, the forms are STRICTLY and rigidly standardized in this industry, and any deviation in format, structure, or presentation is simply not tolerable.
So I was approaching the project by thinking the app would maintain an internal repository of the original standardized forms from the accrediting organization, with each possible data area defined as a field. The app would:
open the necessary PDF form for the task at hand;
parse its dictionary to identity the specific data fields;
for every single field, identify the relevant data from the iOS app's own user interface and data tables, and assign that data to the corresponding field from the PDF/dictionary
export the PDF to a NEW PDF file, which the app would either email or store through iCloud, Dropbox, or some other form of file sharing.
The catch with #4 is that that PDF file must remain editable by standard PDF applications on Windows and Mac (Acrobat, Preview, etc.), so all the fields need to remain. And the PDF should be viewable just the same on either Windows or Mac.
Now, at NO time will the PDF (neither the original nor the exported final document) EVER need to be displayed inside the iOS app, nor would it make much sense to be able to do so.
I don't know if any of this is possible. This is our first iOS project, and we've been leaning towards building the app using Moai or Corona or some other framework to save development time and make porting across platforms easier. That said, if it cannot be done using Lua and one of these frameworks (I remain skeptical...they seem HIGHLY geared towards games), we're not opposed to doing it directly in Objective C and building an Android version some time down the road.
But either way, I'm at a loss in assessing whether this is even a practical undertaking. Our requirements are clear, and frankly if this can't be done, the project won't be pursued any further. But I could definitely use some help from you folks in identifying what my options are, whether I can do it in Lua, and what SDK(s) would be most useful in accomplishing this.
Based on what you've said, it seems that there is little reason to do the PDF-based part of the work on the mobile device itself since:
you don't need to display it on the ipad
you plan to email it or store it in the cloud
if you write this for iOS you will have to write again for Android as you've mentioned
Can you simplify the mobile part of your requirement by focusing on the data-collection and validation, then firing off to a server to do the document production? That will give you a lot more flexibility in the tools that you can use to merge the data into PDF docs. If so you could look at creating PDFs or populating the fields from code using something like iText (C# or Java). If you don't want to build your own back end server you could try something like Docmosis Cloud - but that might not allow you to get your precise layouts.
Certainly the catch you mentioned - needing to keep the PDFs editable with their fields is a significant gotcha in all cases. If you could convince the stakeholders that it is better to generate the final documents from your system (generate draft, review, update data, generate again etc) - rather than generating editable documents that you then lose control and tracability over, then you will be miles ahead.
Hope that helps.
Did you consider just generating a new pdf using an image of the form as the background to the pdf and just writing the user's data into the required areas over the form image. Would reduce the complexity of trying to parse the original form PDFs.
That's a point of worthwhile discussion, but one we don't have an ideal answer on. I tend to think of that as the almost perfect scenario -- it'd be considerably easier to develop. There are two key issues with this approach that have made us table it except as a very last resort:
The users of this product would be working in the field. That field could be quite literally anywhere--the streets of Manhattan, a disaster-stricken area with infrastructure that's been severely damaged or even destroyed, or the most war-ravaged third world country. If it were the streets of, say, Manhattan, there's no problem--their iOS or Android device will have 3G or Wi-Fi access just about anywhere they go. In the latter two scenarios (which are arguably more common in this industry), that connectivity may be very limited. The concern is whether the end user's ability to be productive or to see and share data with their colleagues will be too greatly restricted if they don't have a decent signal. To be fair though, even today they often aren't even using mobile devices, forcing them to go back to a headquarters type location or use radios to share information, effectively negating my point here. But if we're not going to significantly increase their productivity in the field, it just gives us pause to think through whether or not we have enough of a value proposition to ask them to fairly significantly change their methods of doing things.
To your latter point, no there's no convincing the stakeholders that this new system is the better approach. Even if there were, it would take years to do so. These forms are a part of a well-defined, decades-old standard used by literally thousands of organizations.
I need to improve a screen in our Application that presents an HMI (Human Machine Interface) display embedded in our Delphi code. This screen provides our customer with the ability to perform a range of actions (run test, product report etc) and to expose and view key named data values. This customisation is required because our Application controls machinery that might be operated by a range of skill levels from simple operator (may not speak English and must have very limited control) through to a power user who wishes to 'see everything' and have max control.
Some years back I created a solution based on an embedded HTML viewer (Turbopower's as it was then) and TPageProducer to dynamically tweak an HTML template (that the user could customise) and which would display a simple set of controls and data tables. This works fine but is slow to edit (you have to tweak the template and look-see the effect) and I'm sure there are better ways now.
What I need is similiar to a Delphi form that can be customised at runtime. I need: buttons, labels and edits. Editable shapes and arrows are desireable as are fixed images over which controls and text can be laid. The layout should be saveable (like a DFM file) and text labels should be of two types - fixed text and those which update to display key values on an update notification (like a DB control would). The final layout should zoom its scale to fit a resizable layout.
This question is about the best tool for the job and I'm not coming into this totally cold, I've experimented with Greatis Form Designer and obtained a working solution but before I commit, I would apprecaite comments about whether a report tool (with built-in report editor) would be possible / useable / better since a print dump feature would also be useful. (Fast Reports? Quick Report etc?). Note though that this is a display requirement primarily. Comments re newer embedded HTML solutions would also be welcome as would anything to ensure max future-proofing of the layout format.
Any solution should be useable in Dephi 7 (for now!) and does not need to be unicode as long as there is a migration path to this for newer Delphi's.
Any other comments or observations would be very welcome. Thanks.
Have you looked first at the free JVCL stuff? There's a JvInspector (RTTI component property inspector, just like Delphi property inspector), and a form designer, and so on. You could roll your own solution based on these, and even use JvInterpreter for some scripting capability.
Secondly, if you can support ANY control that you have, in your designer, and you need some HMI specific stuff, check out IOCOMP: http://www.iocomp.com/
TMS Scripter Studio Pro provides a Delphi-like IDE and form designer with scripting, but it maybe overkill for your requirements.