i am writing a web application with React, where users can write protocolls for their appointments. The current system is: the web application saves the word file in the local file system, the user edits it and uploads it via a macro in word.
That seems a bit clunky to me and i am not so sure about the security issues of letting the browser directly access the local file system.
So i wanted to let the users edit the files directly via the browser, with an editor similar to GoogleDocs.
Problem is:
Documents have to remain on premis
Converting doc files to a format that can be displayed in a browser and back seems to have some formating issues.
The user must be able to download the file and edit it, in case they have an appointment without internet access and upload it later. So it has to be at least convertable to a document that can be easily edited in Word.
There are so many richtext editor, but from what ive seen none is designed for that use-case. So my question is: Is what i want to do even possible, and if so does anyone know a good editor or library for doing so?
I am looking at how to implement PDF merging with raw VB code so that the code may be invoked by a bot for business process automation.
The software used to create the bot provides a function to invoke VB code, but I don't believe it can access any externally imported libraries because it expects plain source, so I essentially need to produce code that one could run in a VB shell environment without anything fancy (or convenient, it seems).
All the research I've done so far point me in the direction of external packages I would need to install, such as iText; this is what I'm looking to avoid.
(previous iText employee here)
PDF is not an easy (binary) format.
Essentially, blobs of information (text that has to be rendered, fonts, images, vector graphics, etc) are compressed and gathered into objects.
Each object gets a number. Objects are allowed to reference eachother (a piece of text might say 'I want to be rendered with font 4433')
All object numbers and their byte offset in the file are gathered in the crossreference (often called XREF) table.
A PDF includes a 'Pages' dictionary object that tells the viewer which objects belong on which page.
In order to merge PDF files, you would need to:
- read all XREF tables of all files
- adjust all of those to the correct byte offset
- update various dictionary objects within the PDF file that tell it where all the objects per page are kept
This is by no means a trivial task, but it can be done using only VB.
If you are serious about implementing a robust, scalable version of this of tool, perhaps it's better to look at the iText sourcecode and try to port it to VB?
I'm making app with ~200 text files, each file contains ~50000 symbols (it will contain more files later). App will work offline, so text must be prepopulated. First thing about which I thought was usage of databases. But after I googled, I found that it's currently not possible to access SQL prepopulated databases in Phonegap without writing native code and other databases max sizes are too small for my needs.
I need only to read data (writing isn't necessarily).
Is it possible using database?
Is it ok to use JSON/XML/HTML/other file or separate files to store needed text? Won't it cause performance problems?
Is there more suitable approach?
I have implemented a report in standard WPF controls and have also implemented a DocumentPaginator to take these controls and convert them into a document for printing.
I have also implemented some code which uses the document paginator to render the pages to images and write them out to a PDF using PDFSharp, however this does not allow for copying and pasting, also the image quality is questionable.
I have experimented with the GhostXPS utility and was thinking of using it by saving out to an XPS document and then using GhostXPS to convert it to a PDF, this was promising, however the current version contains a bug that renders data copied from the generated PDF useless...
So I thought I would ask here to try and find a efficient method for doing this, Can someone please suggest a good way to take a DocumentPaginator and either save it directly out to a PDF, with copy/paste functionality or convert it from an XPS document to a PDF with this functionality?
Thanks,
Alex.
EDIT - PDFSharp fix:
Ok as requested here is what I did to compile the fix for the PDFSharp 1.31 XPS converter:
1) I downloaded the source from here:
PDFSharp - SourceForge
2) I followed the instruction in this post:
PSFSharp Fix
XpsParser.ImageBrush.cs (ln 22, added): brush.Opacity = 1;
PdfContentWriter.cs (ln 526, changed): if (opacity <= 1)
3) Then just compile the source, first open the 'PdfSharp-WPF.csproj' and build that, then open the 'PdfSharp.Xps.csproj' and build it as well, the relevent libraries are 'PdfSharp-WPF.dll' and 'PdfSharp.Xps.dll'
Note upon trying to build the source you will likely receive a few errors depending on which version of .NET you are targeting, these are simple to fix if you just read the error messages.
EDIT(2): NJones created a blog post with more details on the PdfSharp fix: Output to PDF in WPF
There is an XPS Converter that was included with PDFsharp 1.31. It's a beta version, but AFAIK it supports nearly everything and may work for your needs.
PDFsharp 1.31 can be downloaded from SourceForge or CodePlex.
If a commercial SDK would be an option, there is one company I came across that has a professional XPS to PDF conversion option (and more).
http://www.nixps.com
Warning: I'm not affiliated with this company nor have I tried their products. I have on the other hand heard good things about them.
I use Telerik Reporting which handles document pagination and allows you to create reports in a designer similar to creating a GUI. I decided to just buy a 3rd party product because I didn't want to spend development time writing my own paginator, etc. Also, this tool is probably more bug proof then a custom solution and allows a lot of flexibility for how you want to design your printout/report. In the future if you have more complicated printing or reports required, this tool does a lot more. I do not work for Telerik, but there product is good.
It allows exporting to PDF, Word, Excel, HTML, PowerPoint, PNG, etc. etc.
IMHO, you've got the right idea: XPS is, in my mind, the simplest method of serializing the data into a usable format, especially for conversion.
As for a third party tool, I've a peer (as in, not myself,)who's used CheckPrixa with some measure of success; it's freeware and it offers command line conversions. (i.e. serializing a document and converting a la generated .bat file.)
It also allows you to handle keywords, titles, etc. along with more important items like even pagination.
As far as I'm aware, there are no known discrepancies.
Alternatively, if converting the MSXPS is what's giving you headaches, you might want to look at XpsConverter, it converts MSXPS to OpenXPS, and as a Window's driver, it's available on any machine using .NET 3 and above.
Keep us updated with whatever solution you try, virtual reports are a growing deal.
Yes, I know. This question have been already replied in Where to store the Core Data file? and in Store coredata file outside of documents directory?.
#Kendall Helmstetter Gelner and #Matthias Bauch provided very good replies. I upvoted for them.
Now my question is quite conceptual and I'll try to explain it.
From Where You Should Put Your App’s Files section in Apple doc, I've read the following:
Handle support files — files your application downloads or generates and
can recreate as needed — in one of two ways:
In iOS 5.0 and earlier, put support files in the /Library/Caches directory to prevent them from being
backed up
In iOS 5.0.1 and later, put support files in the /Library/Application Support directory and apply the
com.apple.MobileBackup extended attribute to them. This attribute
prevents the files from being backed up to iTunes or iCloud. If you
have a large number of support files, you may store them in a custom
subdirectory and apply the extended attribute to just the directory.
Apple says that for handling support files you can follow two different ways based on the installed iOS. In my opinion (but maybe I'm wrong) a Core Data file is a support file and so it falls in these categories.
Said this, does the approach by Matthias and Kendall continue to be valid or not? In particular, if I create a directory, say Private, within the Library folder, does this directory continue to remain hidden both in iOS 5 version (5.0 and 5.0.1) or do I need to follow Apple solution? If the latter is valid, could you provide any sample or link?
Thank you in advance.
I would say that a Core Data file is not really a support file - unless you have some way to replicate the data stored, then you would want it backed up.
The support files are more things like images, or databases that are only caches for a remote web site.
So, you could continue to place your Core Data databases where you like (though it should be under Application Support).
Recent addition as of Jan 2013: Apple has started treating pre-loaded CoreData data stores that you copy from a bundle into a writable area, as if they were a support file - even if you write user data into the same databases also. The solution (from DTS) is to make sure when you copy the databases into place, set the do-not-backup flag, and then un-set that if user data is written into the database.
If your CoreData store is purely a cache of downloaded network data, continue to make sure it goes someplace like Caches or has the Do Not Backup flag set.