Not so long ago I started working with the Poppler library. Learned how to get data from a pdf file. But the question is that I need to modify this file. For example, add a new blank page and save it as a PDF. On the Internet, it is mainly described how to get data, but not make changes to the file.
The OP has recognized there are no creative features in the poppler utilities library (which are a spin off from xpdf utilities)
Xpdf PDF file viewer widget and family do have some modify pdf abilities but as part of a wider suite of QT applications.
Poppler is aligned with Cairo which is designed to produce consistent output on all output media. However editing/altering PDFs is not its aim.
You can use poppler to achieve the requested task in a roundabout fashion, but it's very limited for similar tasks or content editing.
The direct answer to the question is to use poppler to split the source
so for example to add in a blank page 3 into a 3 page source (thus pushing existing page 3 to 4)
pdfseparate.exe -f 1 -l 2 layout.pdf page%d.pdf
pdfseparate.exe -f 3 -l 3 layout.pdf page4.pdf
pdfunite.exe page1.pdf page2.pdf inserted.pdf page4.pdf newlayout.pdf
However this is NOT a recommended method as many similar related issues will be found in Q&A, since the new file is usually bloated by duplicated resources, and much of the internal links in the source suffer collateral damage.
For this task a more dedicated manipulation app is required such as say cpdf
Related
I've been tasked with creating a deployable version of a ColdFusion web app to be installed on a clients server. I'm trying to find a way to give them a compiled version of our code, and my first inclination was to use the CFCompile utility that I found here. However, after running CFCompile, most of the code in the CFM files is still readable. The only thing that appears to be obfuscated at all is the actual ColdFusion code - all of the SQL Queries are still perfectly readable. (Example in the screenshot below)
The HTML and JavaScript are also still readable in the compiled code, but that doesn't matter as those can be seen in a web browser anyways.
Is there another way to distribute my source code in a format that is completely unreadable to the user? I'm guessing that for whatever method I choose, there will be some way of decompiling the code. That's not an issue, I just need to find a way to make it more difficult than opening the file and seeing the queries.
Hostek has a pretty good write up on the subject over on their site - How to Encrypt or Compile ColdFusion Files.
Basically, from that article:
Using cfcompile.bat
The cfcompile.bat utility will compile all .cfm and .cfc files within a given directory into Java bytecode. This has the effect of making your source code unreadable, and it also prevents ColdFusion from having to compile your ColdFusion files on first use which provides a small performance enhancement.
More details about using cfcompile.bat can be found in ColdFusion's Documentation
Using cfencode.exe
The cfencode.exe utility will apply basic encryption to a specific file or directory. If used to encrypt a directory, it will apply encryption to ALL files in the directory which can break any JS, CSS, images, or other non-ColdFusion files.
They do also include this note at the bottom:
Note: Encrypting your site files with cfencode does not guarantee absolute security of your source code, but it does add a layer of obfuscation to help prevent unauthorized individuals from viewing the source.
The article goes on to give basic instructions on how to use each.
Adobe has this note on their site regarding cfencode:
Note: You can also use the cfencode utility, located in the cf_root/bin directory, to obscure ColdFusion pages that you distribute. Although this technique cannot prevent persistent hackers from determining the contents of your pages, it does prevent inspection of the pages. The cfencode utility is not available on OS X.
I would also add that it will be trivial for anyone familiar with ColdFusion to decode anything encoded with this utility because they also provide the decoder.
I have an application that relies on many images. I have no problem loading the images on to the window. I would like to make my application have the images integrated into it where there are no actual image files in the folder. Also, I would like to know how to do this, because if I sell the application I don't want the user to be able to go to the directory my .exe is located in an get the image file (I am aware that they can print screen it). So, how can I integrate the image into my application. I am using the WinAPI with C++.
I have searched this multiple times and have not found anything on this. I have found one question on another forum, but it was asked a long time ago and was not answered. I did find one other place that had this, but It did not specifically work with my question.
You can bind images (as well as pretty much any pieces of data) as resources to your binary.
I am writing a program that produces a formatted file for the user, but it's not only producing the formatted file, it does more.
I want to distribute a single binary to the end user and when the user runs the program, it will generate the xml file for the user with appropriate data.
In order to achieve this, I want to give the file contents to a char array variable that is compiled in code. When the user runs the program, I will write out the char file to generate an xml file for the user.
char* buffers = "a xml format file contents, \
this represent many block text \
from a file,...";
I have two questions.
Q1. Do you have any other ideas for how to compile my file contents into binary, i.e, distribute as one binary file.
Q2. Is this even a good idea as I described above?
What you describe is by far the norm for C/C++. For large amounts of text data, or for arbitrary binary data (or indeed any data you can store in a file - e.g. zip file) you can write the data to a file, link it into your program directly.
An example may be found on sites like this one
I'll recommend using another file to contain data other than putting data into the binary, unless you have your own reasons. I don't know other portable ways to put strings into binary file, but your solution seems OK.
However, note that using \ at the end of line to form strings of multiple lines, the indentation should be taken care of, because they are concatenated from the begging of the next lineļ¼
char* buffers = "a xml format file contents, \
this represent many block text \
from a file,...";
Or you can use another form:
char *buffers =
"a xml format file contents,"
"this represent many block text"
"from a file,...";
Probably, my answer provides much redundant information for topic-starter, but here are what I'm aware of:
Embedding in source code: plain C/C++ solution it is a bad idea because each time you will want to change your content, you will need:
recompile
relink
It can be acceptable only your content changes very rarely or never of if build time is not an issue (if you app is small).
Embedding in binary: Few little more flexible solutions of embedding content in executables exists, but none of them cross-platform (you've not stated your target platform):
Windows: resource files. With most IDEs it is very simple
Linux: objcopy.
MacOS: Application Bundles. Even more simple than on Windows.
You will not need recompile C++ file(s), only re-link.
Application virtualization: there are special utilities that wraps all your application resources into single executable, that runs it similar to as on virtual machine.
I'm only aware of such utilities for Windows (ThinApp, BoxedApp), but there are probably such things for other OSes too, or even cross-platform ones.
Consider distributing your application in some form of installer: when starting installer it creates all resources and unpack executable. It is similar to generating whole stuff by main executable. This can be large and complex package or even simple self-extracting archive.
Of course choice, depends on what kind of application you are creating, who are your target auditory, how you will ship package to end-users etc. If it is a game and you targeting children its not the same as Unix console utility for C++ coders =)
It depends. If you are doing some small unix style utility with no perspective on internatialization, then it's probably fine. You don't want to bloat a distributive with a file no one would ever touch anyways.
But in general it is a bad practice, because eventually someone might want to modify this data and he or she would have to rebuild the whole thing just to fix a typo or anything.
The decision is really up to you.
If you just want to keep your distributive in one piece, you might also find this thread interesting: Store data in executable
Why don't you distribute your application with an additional configuration file? e.g. package your application executable and config file together.
If you do want to make it into a single file, try embed your config file into the executable one as resources.
I see it more of an OS than C/C++ issue. You can add the text to the resource part of your binary/program. In Windows programs HTML, graphics and even movie files are often compiled into resources that make part of the final binary.
That is handy for possible future translation into another language, plus you can modify resource part of the binary without recompiling the code.
Is there a library that will allow easier generation of a simple website using C++ code. This 'website' will then be compiled into a CHM help file (which is the final goal here). Ideally, it will allow generation of pages easily and allow links to be generated between pages easily. I can do this all by hand, but that is going be very tedious and error prone.
I know about bigger libraries such as Wt, but am more interested in smaller ones with little or no dependencies and a need for installation.
You can try CTPP template engine. It is written in C++ is small and quite fast.
Do you need this project to be written in c++? Because if you just need to prepare documentation in CHM I would go with Sphinx. Sphinx is a set of tools written in Python that generate manuals in few formats (chm, html, LaTeX, PDF) from text files (formated using reStructuredText markup language). Those text files could be created by hand or using some application and then combined into one manual using Sphinx. In my work right now we are using this solution to write documentation, because it is very easy to maintain text files (merging, tracking changes etc.) than for example html or doc. Sphinx is used to generate Python language documentation (chm), so it is capable to handle really large project.
I've used the FLATE library every day for ten years and it works flawlessly. It's a piece of cake to use; I can't recommend it enough.
It will definitely do the trick, though probably at a much lower level than you have in mind. It is a C-language source library that you can link with a C++ caller. It's also available as a Perl module, but I haven't used that.
FLATE library
Flate is a template library used to deal with html code in CGI applications. The library includes C and Perl support. All html code is put in an external file (the template) and printed using the library functions: variables, zones (parts to be displayed or not) and tables (parts to be displayed 0 to n times). Using this method you don't need to modify/recompile your application when modifying html code, printing order doesn't matter in your CGI code, and your CGI code is much cleaner.
HTH and good luck!
Are this CHM lib and the related links what you're looking for?
I have a substantial body of source code (OOFILE) which I'm finally putting up on Sourceforge. I need to decide if I should go with a monolithic include directory or keep the header files with the source tree.
I want to make this decision before pushing to the svn repo on SourceForge. I expect a lot of people who use it after that move will keep a working copy checked out directly from SF so won't want to change their structure.
The full source tree has about 262 files in 25 folders. There are a lot more classes than that suggests as due to conforming to 8.3 character names (yes it dates back to Win3.1) many classes are in one file. As I used to develop with ObjectMaster, that never bothered me but I will be splitting it up to conform to more recent trends to minimise the number of classes per file. From a quick skim of the class list, there are about 600 classes.
OOFILE is a cross-platform product expected to be built on Mac, Windows and assorted Unix platforms. As it started life on Mac, with compilers that point to include trees rather than flat include dirs, headers were kept with the source.
Later, mainly to keep some Visual Studio users happy, a build was reorganised with a single include directory. I'm trying to choose between those models.
The entire OOFILE product covers quite a few domains:
database front-end
range of database backends
simple 2D graphing engine for Mac and Windows
simple character-mode report-writer for trivial html and text listing
very rich banding report-writer with Mac and Windows Preview and Printing and cross-platform generation of text, RTF, HTML and XML reports
forms integration engine for easy CRUD forms binding to the database, with implementations on PowerPlant and MFC
cross-platform utility classes
file and directory manipulation
strings
arrays
XML and tag generation
Many people only want to use it on a single platform and some of those code areas are pure legacy (eg: PowerPlant UI framework on classic Mac). It therefore seems people would appreciate not having headers from those unwanted areas dumped in their monolithic include directory.
I started thinking about having an include directory split up into a few of the domains above and then realised that was sounding more like the original structure.
In summary, the choices seem to be:
Keep original model, all headers adjacent to source - max flexibility at cost of some complex includes in projects.
one include directory with everything inside
split includes by domain, so there may be about 6 directories for someone using the lot but a pure database user would probably have a single directory.
From a Unix build aspect, the recommended structure has been 2. My situation is complicated by needing to keep Visual Studio and XCode users happy (sniff, CodeWarrior, how I doth miss thee!).
Edit - the chosen solution:
I went with four subdirectories in include. I started trying to divide them up further by platform but it just got very noisy very quickly.
Personally I would go with 2, or 3 if really pushed.
But whichever you choose, please make it crystal clear in the build instructions how to set up the include paths. Nothing dooms an open source project more than it being really difficult to build - developers want a quick out-of-the-box experience and if it involves faffing around with many undocumented environment variables (or whatever) most will simply go away.