Years ago, I wrote a small app in itext2 to gather reports on a weekly basis and concatenate them into one PDF. The app used com.lowagie.text.pdf.PdfCopy to copy and merge the PDFs. And it worked fine. Performed exactly as expected.
A few weeks ago I looked into migrating the application to itex7. To that end, I used the copyPagesTo method of com.itextpdf.kernel.pdf.PdfDocument. When run on the same file set, this produces warnings like:
WARN PdfNameTree - Name "section.1" already exists in the name tree; old value will be replaced by the new one.
When I click on the link to "section.1" in the first document of the merged PDF, I am taken to "section.1" of the last document. Not what I expected and not what happens when using the itext2 app. In the PDF's produced by itext2, if I click on the link to "section.1" of the first document in the combined PDF, I am taken to section 1 of the first document.
There is a hint in Javadocs for copyPagesTo saying
If outlines destination names are the same in different documents, all
such outlines will lead to a single location in the resultant
document. In this case iText will log a warning. This can be avoided
by renaming destinations names in the source document.
There is however, no explanation of how this should be done. I find it odd that this should be necessary in itext7, although it wasn't in itext2.
Is there a simple way to get around his problem?
I've also tried the Sejda desktop app and it produces correct results, but I would prefer to automate the process through a batch script.
My guess is iText 2 didn't even know it might be a problem.
If iText can't deduplicate destination names, the procedure is roughly:
Follow /Catalog -> /Names -> /Dests in each document to find the destination name tree.
Deduplicate the names, by adding suffixes. Remember that a name with a suffix added might be equal to an existing name in the same or another document. Be careful!
Now you can rewrite the destination name trees. Since you have only used suffixes, you can do this in place - the lexicographic ordering of the names is unaltered so the search tree structure is not broken.
Now, rewrite destination links in each PDF for the new names. For example any dictionary entry with key /Dest, or any /D in a /GoTo action.
Now, after all this preprocessing, the files will merge without name clashes.
(I know all this because I've just implemented it for my own PDF software. It's slightly hairy stuff, but not intractable.)
If you like, I can provide a devel version of cpdf with this functionality, if you would like to test it.
I have a Windows Forms .NET application in Visual Studio. Making a form "Localizable" adds a Form1.resx file nested below the form. I also want to add a separate .resx file for each form (Form1Resources.resx). This is used for custom form-specific resources, e.g. messages generated using the code behind.
This is set up as follows:
It would be tidier to nest the custom .resx file beneath the form (see this question for details about nest how to do this), as follows:
However, this results in the following error when I build the application:
Two output file names resolved to the same output path:
"obj\Debug\WindowsFormsApp1.Form1.resources" WindowsFormsApp1
I'm guessing that MSBuild uses some logic to find nested .resx files and generate .resources file based on its parent. Is there any way that this can be resolved?
Note that it is not possible to add custom messages to the Form1.resx file - this is for design-specific resources only and any resources that you add get overwritten when you save changes in design mode.
The error comes from the GenerateResource task because the 2 resx files (EmbeddedResource items in msbuild) passed both have the same ManifestResourceName metadata value. That values gets created by the CreateManifestResourceNames task and assumingly when it sees an EmbeddedResource which has the DependentUpon metadata set (to Form1.cs in your case) it always generates something of the form '$(RootNamespace).%(DependentUpon)': both your resx files end up with WindowsFormsApp1.Form1 as ManifestResourceName. Which could arguably be treated as the reason why having all resx files under Form1 is not tidier: it's not meant for it, requires extra fiddling, moreover it could be confusing for others since they'd typcially expect to contain the resx fils placed beneath a form to contain what it always does.
Anyway: there's at least 2 ways to work around this:
there's a Target called CreateCustomManifestResourceNames which is meant to be used for custom ManifestResourceName creation. A bit too much work for your case probably, just mentioning it for completeness
manually declare a ManifestResourceName yourself which doesn't clash with the other(s); if the metadata is already present it won't get overwritten by
Generic code sample:
<EmbeddedResource Include="Form1Resources.resx">
<DependentUpon>Form1.cs</DependentUpon>
<ManifestResourceName>$(RootNamespace).%(FileName)</ManifestResourceName>
...
</EmbeddedResource>
IS there a way to add/initate a comment ( e.g. $dom->createComment ... ) such that it comments out an entire block of xml tags. Basically I want to turn-off the content between the comment.
For example, it would look like this:
<TT>
<AA>keep</AA>
<!-- comment to blocking
<BB>hideme1</BB>
<CC>hideme2</CC>
-->
<DD>d's content is good</DD>
</TT>
Actually this question is a pre-cursor to my attempt to figure-out a method to be able to markup/label/identify the changes to an xml files in support of new client software functionality, but be able to have the ability to remove / back-out these xml changes in the rare event the client needs to fall back to the previous software version (and no I can't just simply point back to the original xml file because the client is allowed to make minor modifications to existing node text values). This is all going to be controlled via a perl script and LibXML's core modules (I can't use modules the client doesn't have).
So basically I've identified three possible types of xml changes as a result of new client sw functionality:
1.) ADD new element node(s) (typically to support new sw functionality)
2.) DELETE element node(s), or blocks of (would be rare, but never-the-less a possibility)
3.) CHANGE node text values (rare, but the new sw may require a new value)
For all three types, the client needs the ability to back out the changes. One thing I was thinking to use is ATTRIBUTES since the existing xml files don't use them. For example, for an ADD change type, I could include an atribute like 'ADD="sw version 4.1"' . This way if it needs to be removed, I could just simply have the perl script find those attribute strings and delete them (using LibXML methods). Same thing with CHANGE change type - I could use an attribute like CHG="newvalue_oldvalue", then again use straight perl (or LibXML) to switch back the value based on the contents of the attribute. The DELETE change type is giving me a problem though (as welll as the others lol!). I want to be able to "keep" the deleted lines in the xml file soley for the purposes if the sw falls back a version (at some late point the perl script could eventually cleanup/delete them).
I know this is a lot, I'm new to LibXML (but not to perl). I was just wonder if any of you have any thoughts as to how to go about it or seen anything resembling this kind of request ... I'd be grateful for any kind of advice! Thank you...
I searched for a couple of days to fix this bug with nothing new.
I had a report which include multi-level subreports everything works fine on iReport 3.7.5. I used subreport.jasper as subreport expression in the first level & also subreportA.jasper, subreportB.jasper in the second level & place all (the main report & subreports) in the same path.
The problem raised when I try to deploy it on my JasperServer.
When I try to upload the first main report the iReport wizard offerd me to attach the first subreport.jrxml in resource folder and access it with repo:subreport.jrxml or repo:subreport.jasper.
Then I manually upload the second level subreports and do the same thing change the subreport expression to repo:subreportA.jasper and repo:subreportB.jasper.
I got compilation error : Unable to locate the subreport with expression: ""repo:subreport.jasper"". java.lang.Exception: repo:subreport.jrxml not found.
I try dozen solution and nothing works.
using : SUBREPORT_DIR # the beginning,
using full path : repo:/Circuit_Reports/Connectivity/Connectivity_files/,
switch between .jasper & .jrxml.
using jasperserver_api_engine_impl_0_fix.jar in lib folder as a fixation to this bug,
I also searched the database record to be sure that they are in the same folder and have the same parent folder.
Smalltalk before Longtalk ;)
(Of course I don't want to encourage you to read everything of this long detailed post! The bold markers may already be enough to solve your problems but I found it worth documenting this tricky stuff in some more detail!)
Since I invested another couple of hours on this (after I resolved it some weeks ago, had a change now, but forgot to document it properly, forgot how I did it and could not retrieve this info again in any form - when uploading and configuring to/in JasperServer) ... here is some aggregated functionality mentioned on various sites regarding subreport referencing, how it works and what one can try ...
(I'll update mine or other findings in here if there hopefully will be some)
Short cut details / best practices?!4
Till maybe Jasper functionality provides a similar "wrapping" solution itself ...
To workaround all the problems related to running the *.jrxml, *.jasper files either locally in Preview mode or remotely on a JasperServer I am now using the following approach which allows to work with only a single *.jrxml file, that will work locally and remotely without modifications, in a multi-developer environment, supporting independent refactoring of dir structures (paths, names) per environment (= as it should ;-) ):
using some jasper-utils-*.jar
put it in your project (Java) class path (Project->Properties->Java Build Path->Libraries->Add)
put it in your ../jasperserver/WEB-INF/lib/ folder
referencing some custom Jasper Java Scriptlet jr.utl.EnvScriptlet that does the ugly subreport path/reference magic in your master reports
define the REPORT_SCRIPTLET by adding an attribute to your master report: report properties -> Report -> Data Set -> Scriptlet Class: jr.utl.EnvScriptlet
using some custom properties file jr.utl.properties or otherwise supplied system properties (any other way to set the Java system properties would be fine as well and work - where already set up properties will override loaded file properties) to configure the different environments including your
current environment information via jr.utl.env property (prod, myOsUsrName, test, demo, staging, local, ...)
which determines how the subreport references must be generated / look like
server subreport parent directory property references
take e.g. these property file contents and put one per environment here:
on your servers: ../jasperserver/WEB-INF/classes/jr.utl.properties
jr.utl.env=prod
mycompany.local.jr.gui.rep.subrep1.parentdir=repo:/x/y/z/
mycompany.local.jr.gui.rep.subrep2.parentdir=repo:/x/y/z/
mycompany.local.jr.gui.rep.subrep3.parentdir=repo:/x/y/foobar/
in your local JasperSoft Studio (Eclipse) Java src/build path: e.g. ../myrepproject/src/java/jr.utl.properties
jr.utl.env=dietrian
mycompany.local.jr.gui.rep.subrep1.parentdir=D:/reporting/src/reports/
mycompany.local.jr.gui.rep.subrep2.parentdir=D:/reporting/src/reports/
mycompany.local.jr.gui.rep.subrep3.parentdir=D:/reporting/src/reports.otherdir/
to achive source modification independency in our environments we parameterized those values and generate them once via some workspace-dependent/user-specific local.properties file, based on this idea:
|- build.xml (containing the ANT build magic)
|- build.properties (containing global properties)
|- local.properties (ignored in version control, e.g. .hgignore, user-specific generated from local.template.properties)
|- local.template.properties (source for ANT build task generating the local.properties above)
|- mycomp.local.proj.reporting.dir=D:/reporting
|- src/reports
|- jr.utl.properties (ignored in version control, user-specificly generated based on template below)
|- jr.utl.template.properties (source for ANT build task generating the jr.utl.properties above)
jr.utl.env=${user.name}
mycompany.local.jr.gui.rep.subrep1.parentdir=${mycomp.local.proj.reporting.dir}/src/reports/
mycompany.local.jr.gui.rep.subrep2.parentdir=${mycompany.local.jr.gui.rep.subrep1.parentdir}
mycompany.local.jr.gui.rep.subrep3.parentdir=${mycomp.local.proj.reporting.dir}/src/reports.otherdir/
defining your BASE_DIR master report parameters as e.g.
$P{REPORT_SCRIPTLET}.getProp("mycompany.allsubreports.parentdir") (matching some environment-dependent property in your jr.utl.properties file)
defining the master subreport expressions as e.g. jr.utl.EnvScriptlet.getSubrepPath( $P{BASE_DIR}, "subrep1.jrxml")
automatically resolving the values from properties you could also use e.g. these variants:
jr.utl.EnvScriptlet.getSubrepPathByPropKey( $P{BASE_DIR}, "mycompany.local.jr.gui.rep.subrep1.name")
jr.utl.EnvScriptlet.getSubrepPathByPropKeys( "mycompany.local.jr.gui.rep.subrep1.parentdir", "mycompany.local.jr.gui.rep.subrep1.name")
$P{REPORT_SCRIPTLET}.getSubrepPath(...) does not work here :-( (I don't know why)
do not forget to restart your server when you put all the files on the server!
(4: Of course I am still seeing some minor improvements here, but it seems much better than all the ugly solutions I found till now. Improvements I would see:
using the REPORT_SCRIPTLET or scriptlet functionality may not be the best way to go, but it will probably work in the vast majority of use cases
although both existing Jasper classes suggest this they do not seem to be able to handle the above properly:
FileResolver
RepositoryUtil
)
(5: the relevant special handling is encoded here: EnvScriptlet.java/getSubrepPath(String,String,boolean,String[]))
Intro (Background)
First thing to know is that the handling/setup in JasperStudio is quite different from the handling on Jasper Server (Repository)5 ...
suppose we have the following enviroments:
our Eclipse install dir: C:\eclipse\
our Eclipse (Report) workspace: C:\workspace\
our report project under: C:\workspace\report-project\
our reports under: C:\workspace\report-project\src/reports
a master report C:\workspace\report-project\src/reports/masterrep.jrxml
some subreport C:\workspace\report-project\src/reports/subrep1.jrxml
another subreport C:\workspace\report-project\src/reports/somesubdir/subrep2.jrxml
the BASE_DIR (explained in next section) in our workspace master report is set to C:\workspace\report-project\src/reports/
our Jasper Report Server GUI repo id-path of our master report will be: /x/y/z/
(which is not to-be-confused with the visual named-path, e.g. which could be Financial Reports/Expenses/Current Year)
In general: Jasper Studio, JasperServer
(and other "Jasper runtime environments" like custom Java Jasper package usage):
it seems a good practice to declare a report parameter "prefix" which can vary depending on your Jasper runtime environment e.g. named BASE_DIR
important here is that it seems best to assume the suffixed / may be included1 because there are cases where you may have/want to use it in a way where it should be an empty or "unslashed" path expression
e.g. $P{BASE_DIR} + "subrep1.jrxml" which should resolve to
repo:subrep1.jrxml
see e.g. here for more details (look for SUBREPORT_DIR)
(1: which I personally find a bad practice in general (not looking at Jasper Reports in this respect) when dealing with directory-like structures)
JasperStudio Designer (Eclipse Plugin)
(the official IReport successor with loads of more functionality)
(if you do not use the preview functionality this may be uninteresting to you)
unfortunately I found no practical way to fully support (normal) "team-development" with subreports (and likely other relative resources as well), meaning here the (currently to me unknown) inexistent possiblity to separate local paths and *.jrxml files :-(
e.g. if you have a version control system in place and work in different environments (different local paths to repos and/or different developers) the master report has to contain a local path to your subreport in some way)
I tried different approaches that failed:
relative path expressions in BASE_DIR do not work since the working directory is the eclipse dir, e.g. C:\eclipse
Eclipse->Window->Preferences->JasperStudio->Properties->Add e.g. my.base.dir
it is not available in the Preview mode, e.g. via new java.io.File(System.getProperty("my.base.dir")).getCanonicalPath() + "/" for our BASE_DIR expression (these props may be only used by the designer itself, but not set in preview runs)
just in case you may stumble upon (as I did): Eclipse->Window->Preferences->JasperStudio->Report Execution->Virtualizer Temporary Path is something unrelated (not useful here) dealing with the storage of the report result "caching"
of course I could write an ANT task to replace these local pattern based on a regexp filter copy on every usage/checkout, but that seems not a good way to handle this
if you solely want to work with *.jrxml files (as I do3) you have to reference some subrep1.jrxml like this: net.sf.jasperreports.engine.JasperCompileManager.compileReport($P{BASE_DIR} + "subrep1.jrxml")
(3: I don't need the *.jasper files explicitely and do not see why I want to deal with them. BTW the JasperServer WebGUI only seems to support the upload of *.jrxml files)
JasperServer Web GUI
(e.g. provided by some Tomcat application server and storing its data in some postgres database)
Scenario 1: reference attached subreport resource(s)
if you do not want to reuse your report in general, it seems fine to add your supreport to your master report (so it is not visible in the GUI repo tree - see below subitem how you could reference it outside of your master anyways)
if you attach your subreport it should in general have its file name as its resource id, e.g. our subrep1.jrxml from above is uploaded with a resource id of subrep1.jrxml (thus making the handling of local design references and server references less complicated)
taking the example reports from above we have to set our BASE_DIR to repo: in the to-be-uploaded master report
thus the subreport expressions $P{BASE_DIR} + "subrep1.jrxml" and $P{BASE_DIR} + "somesubdir/subrep2.jrxml" should work on the server as well
NOT recommended!: you could still reference these reports from other reports with absolute paths like this2: repo:/x/y/z/masterrep.jrxml_files/masterrep.jrxml_
(2: which I would not recommend in this case; it's undocumented and may change; better put your subreports then into the "GUI repo path" as described below)
Scenario 2: reference repo subreport resource(s)
suppose we upload our subreports to the master repo id-path /x/y/z/ (as shown on top)
again we have to differentiate two different use cases
we do NOT want to use the subreport as a standalone report (it will always only be included in other master reports)
in this case we should upload it using Add Resource->File->JRXML and reference it
../subrep1.jrxml or ./subrep1.jrxml do not work since it seems the underlying logic cannot handle the relative path expression .. (and likely . not as well) (which would actually be nice :-( )
so what we have to do here is to supply an absolute canonical path in the BASE_DIR of our masterrep.jrxml, e.g. repo:/x/y/z/
we want to use the subreport as a standalone report as well
in this case we should upload it using Add Resource->JasperReport
this obviously creates a hidden folder repo:/x/y/z/subrep1.jrxml_files containing the report itself and other resources
that's why we not only have to adjust the BASE_DIR (as above), but also the subreport expression to, e.g. $P{BASE_DIR} + "subrep1.jrxml_files/subrep1.jrxml_" (which points to the subreport itself)
and maybe remove the net.sf.jasperreports.engine.JasperCompileManager.compileReport(...) wrapper function, because the server does this automatically for *.jrxml files
I did not fully investigate some other likely incorrectly used approaches which did not work for me to solve the mentioned problems (maybe somebody else has some outcome/corrections here):
$P{REPORT_FILE_RESOLVER}.resolveFile("subrep1.jrxml") (NullPointerException)
resulting in empty subreport sections in master report:
$P{REPORT_CONTEXT}.getRealPath("subrep1.jrxml")
$P{REPORT_CONTEXT}.getProperty("REPORT_FILE_RESOLVER").resolveFile("subrep1.jrxml")
Additional hints
Since I like to automate the report design and deployment process as much as it makes sense I wrote some ANT tasks that handle the local *.jrxml file to deployable *.jrxml file transformations regarding the BASE_DIR and the other transformations.
SQL helpful to easily investigate the resource id path structures in a jasper server postgres meta database (following something like jdbc:postgresql://myjasperhost/jasperserver connecting e.g. with the postgres user):
select
f.id as folder_id,
r.id as res_id,
case when f.hidden = true then 1 else 0 end as hidden,
f.uri||case when f.uri = '/' then '' else '/' end||coalesce(r.name,'') as res_uri,
r.resourcetype,
r.creation_date,
r.update_date,
f.uri,
r.name,
-- less important
r.version,
r.parent_folder,
r.childrenfolder,
f.parent_folder,
f.version,
f.name
-- select *
from jiresourcefolder f
left outer join jiresource r on (r.parent_folder = f.id)
where not f.uri like '/themes%'
order by f.uri||coalesce(r.name,'')
Related Questions
Questions on the Jaspersoft forum related to this one include:
http://community.jaspersoft.com/questions/525466/proper-way-include-subreports
http://community.jaspersoft.com/questions/530526/subreport-could-not-load-object-location
http://community.jaspersoft.com/questions/517832/subreports-ireports
http://community.jaspersoft.com/questions/537611/sub-report-jrxml-jasper
http://community.jaspersoft.com/questions/534861/unable-compile-master-report-pls-advise
http://community.jaspersoft.com/questions/817852/databasetimezone
http://community.jaspersoft.com/questions/819343/comjaspersoftjasperserverapijsexception-error-filling-report-and
http://community.jaspersoft.com/questions/536251/solved-subreport-not-running-jasperserver
http://community.jaspersoft.com/questions/536218/resolved-problem-subreport-reference-after-exporting-ireport-jasperserver#81141
http://community.jaspersoft.com/questions/527109/subreport-problem
http://community.jaspersoft.com/questions/522331/atomatically-compile-subreports
Not sure if this mechanism works in all cases but it certainly works for JasperSoft Studio 5.6.0 and Jasper Reports Server 5.6.0.
Essentially we need a simple way to detect that we are running on the server - I use the presence (or absence) of the $P{REPORT_CONTEXT} parameter which experiments show is present on the server but not present during preview.
<parameter name="OnServer" class="java.lang.Boolean" isForPrompting="false">
<parameterDescription><![CDATA[Are we running on server]]></parameterDescription>
<defaultValueExpression><![CDATA[Boolean.valueOf($P{REPORT_CONTEXT}!=null)]]></defaultValueExpression>
</parameter>
Once you have that you can then define the location of your subreport from a choice of two:
<parameter name="SubReportProducts" class="java.lang.String" isForPrompting="false">
<parameterDescription><![CDATA[The products subreport]]></parameterDescription>
<defaultValueExpression><![CDATA[$P{OnServer}.booleanValue() ? "repo:OrderPicksheetProducts.jrxml" : "OrderPicksheetProducts.jasper"]]></defaultValueExpression>
</parameter>
And then include the sub report:
<subreportExpression><![CDATA[$P{SubReportProducts}]]></subreportExpression>
You can then use Preview in studio and all still works when you deploy to server.
I'm not 100% of this answer but : You have to upload your subreport as a jrxml ressource and put "repo://subreport.jrxml" to get it work.
If you read this one of those days tell me if it worked or what solutions you found.
Regards
Try removing the extension completely and use "repo:/subreportFolder/subreportName". The main report pulls the jasper file in iReport, but on the jasperserver you upload the jrxml.
I'm working on automated builds and need to be able to list elements that were worked on under particular activities. I'm new to ClearCase so I apologise for naiivety ...
My downstream build process works fine and I now need to populate a 'pre-build' area by identifying the (checked-in) files associated with one or more activities, labels etc (in fact any combination the change/release manager wants) by listing the candidate files for a build and then copying them from the M: drive (Windows). We are using CC 7.1 with a back end on AIX and Win XP Pro desktops. We'll use ccperl to drive the find+copy process.
I have battled with 'find' to no avail - can someone lend a hand? All help gratefully received.
Cliff.
For "label" (I suppose "UCM Baselines" since you mention "activities", which exist only with UCM):
The easiest way would be to configure a config spec for a dynamic view:
element * MY_BASELINE
in order to quickly access the right files.
For activities, you could (if there is not too much files involved), list the exact versions of each activities you want:
cleartool descr -l activity:my_actity#\pvob
and parse the result to grep/awk only what you need.
You need only to do this within a dynamic view (any dynamic view): the activity will contain a list of extended pathnames, meaning you will be able to access and copy each version through that myFile##/main/myBranch/myVersion path.