Our department has inherited code that uses Apache PDFBox 1.8.x or earlier and we are in the process of trying to migrate it to Apache PDFBox 2.0.x. I have versions of the last three major versions (1.7.x, 1.8.x, and 2.0.x) that I've looked to for guidance as well as the Migration to PDFBox 2.0.0 and the PDFBox Jira Board.
I have resolved a lot of the various issues in this migration, but I'm still having problems migrating some of the TextPosition related code. The project originally forked the TextPosition code and created setters/getters for all the internal TextPosition fields. I realize this breaks the contract of TextPosition (like Java String) being immutable, so I've pulled all that out. We still have some code that relies on the endX/endY fields, but there are no native getters for these fields and they are marked as private, so a subclass can't even access these fields. Are there any recommendations on how to access the endX/endY values?
Also, related to TextPostion, it looks like the PostionWrapper class was dropped on 2.0.x, but I can't find any reference to a replacement for it. What should we use in place of PositionWrapper?
This issue has been resolved by #Tilman adding getters for endX and endY (and for some more values) to PDFBox; for details see the PDFBox issue PDFBOX-3576 created by the OP. The new getters are available from PDFBox version 2.0.5 onwards.
An alternative for the OP would have been to access the members via reflection. But reflection might not be allowed in all contexts, and members which are now part of the public API are less likely to break over time.
Related
After updating MiKTeX, Texmaker and all installed packages, I receive an error when compiling the document. The error message is the following:
Package everypage Warning: Functionality similar to this package has recently been implemented in LaTeX. This package is now in legacy status. Please, don't use it in new documents and packages.
Package everypage Warning: You appear to be running a version of LaTeX providing the new functionality. Doing the best to deliver the original `everypage` interface on top of it. Strict equivalence is not possible, breakage may occur. If truly needed, Use `everypage-1x` to force the loading of an older code base.
The error is caused by the code \usepackage[some]{background}, also without the parameter "some". So the package background has a dependency to the package everypage which causes the error.
The document is compiling, but I would like to resolve the warning. How can I achieve this?
EDIT: Here you can find a compilable minimal example:
\documentclass[a4paper, parskip, 10pt]{scrartcl}
\usepackage[some]{background}%Warning
\definecolor{font}{RGB}{46, 49, 51}
\begin{document}
\color{font}
{\Huge Text}
\end{document}
Here is the cause: There was a recent update to LaTeX, documented here:
LaTeX News Issue 32, October 2020
The updated provided native hook management, including those related to page shipout - something that was provided by everypage. The package maintainer provided an update to everypage stating this:
Package is now in a legacy status. Functionality similar to that
provided by this package is directly implemented in LaTeX since its
2020 Fall release. On new enough LaTeX formats, everypage now merely
emulates its legacy interface on top of the new LaTeX mechanisms for
compatibility reasons, while on older formats, it fall backs to its
own previous code.
Do not use everypage in new documents and do not rely on it in new
packages or classes of yours.
The maintainer of background will have to update the package to utilise the new hooks rather than rely on everypage. Alternatively, write your own background-like macros (whatever that may be).
In the interim you could just suppress the warnings using silence:
\usepackage{silence}
\WarningsOff[everypage]% Suppress warnings related to package everypage
\usepackage[...]{everypage}
I have unknown data which I get it straight from query/datatable How do I use WebApiContrib.Formatting.Xlsx library? which it asks me to have a model for every xlsx reports. I have tried to generate dynamic class from datatable but it doesnt seem working.
This will be possible with the 2.0 release, which supports custom column resolvers and more robust serialisation for ExpandoObject. You can grab the prerelease version now on NuGet, and I plan to document the new functionality over the nice big break I have coming up soon.
I'm looking for a formal definition of version number formats for .NET Core project.json files.
version
Visual studio creates a default version number of "1.0.0-*". I would love for this to mean the * gets updated on successive builds (it doesn't). The build version number is 1.0.0. What does the * mean and what are the legal possibilities?
dependencies
I expected the dependency numbering to follow the nuget versioning rules given that KPM is basically a nuget front-end, but it doesn't appear to support bracket numbering (eg "[1,2)") - I get "not a valid version string" when I try anything other than a blank or x.x-* format.
Outside of the source, does anyone have a link to a formal definition?
I'm not sure what's wrong with looking into the source for a definition. I think that's the most accurate place to search, especially now that vNext is hosted on GitHub.
Looking at the exception described, we're pointed to SemanticVersion.cs.
In the method TryParseInternal, it's fairly obvious why you're running into issues when attempting to declare min/max versions that way. There is simply no handling for [,] or (,) built into that method.
If we look into the regular NuGet version specification, it's obvious that TryParseVersionSpec does have this handling built in.
As for documentation specifying acceptable formats, you'll probably have to wait until it's out of CTP status. If you believe it's an issue, you should document it in GitHub. The contributors are very responsive to these types of issues. Personally I'm not sure if there's a need for setting a maximum version of a dependency when it's deployed with your build.
I have been reading about semver. I really like the general idea. However, when it comes to putting it to practice, I feel like I'm missing some key pieces of information. I'm not sure where the name of a library exists, or what to do with file variants. For instance, is the file name something like [framework]-[semver].min.js? Are there popular JavaScript frameworks that use semver? I don't know of any.
Thank you!
Let me try to explain you.
If you are not developing a library that you like to keep for years to come, don't bother about it.. If you prefer to version every development, read the following.
Suppose you are an architect or developer developing a library that is aimed to be used by hundreds of developers over time, in a distributed manner. You really need to be cautious of what you are doing, what your developers are adding (so interesting features that grabs your attention to push those changes in the currently distributed file). You dont know how do you tell your library users to upgrade. In what scenarios? People followed some sort of versioning, and interestingly, their thoughts all are working fine.
Then why do you need semver ?
It says "There should be a concrete specification for anything for a group of people to follow anything collectively, even though they know it in their minds". With that thought, they made a specification. They have made their observation and clubbed all the best practices in the world about versioning software mainly, and given a single website where they listed them. that is semver.org. Its main principles are :
Imagine you have already released your library with a version "lib.1.0.98", Now follow these rules for subsequent development.
Let your library is bundled and named as xyz and,
Given a version number MAJOR.MINOR.PATCH, (like xyz.MAJOR.MINOR.PATCH), increment the:
1. MAJOR version when you make incompatible API changes
(existing code of users of your library breaks if they adapt this without code changes in their programs),
2. MINOR version when you add functionality in a backwards-compatible manner
(existing code works, and some improvements in performance and features also), and
3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
If you are not a developer or are not in a position to develop a library of a standard, you need not worry at all about semver.
Finally, the famous [d3] library follows this practice.
Semantic Versioning only defines how to name your versions. It does not specify what you will do with your version number afterwards. You can put the version numbers in package names, you can store it in a properties file inside your application, or just publish it in a wiki. All those options are opened to discussion and not part of the problem space addressed by SemVer.
semver is used by npm and bower (and perhaps some other tools) for dependency management. Using semver it is possible to decide which versions of which packages to use if multiple libraries used depend on the same library.
As others have said, semantic versioning is a standard versioning scheme that tells your users which versions of your library should be compatible with each other, and which ones are not.
The idea, is to be able to give your users more confidence that it's safe to upgrade to a newer patch/version, because it's tried, tested, and true to being backwards compatible with the previous version (minor increments). That is, perceptively that's what your telling your users.
As far as tooling goes, I don't do much in javascript, but I typically let my build server handle stamping my assemblies etc with the correct version. I have a static major number I upgrade whenever I make breaking changes, a static minor number I upgrade everytime I add new features, and an auto-incrementing Patch number whenever I checkin bug fixes.
Especially if this is a javascript library you plan to share on a public repository of some kind (nuget, gem, etc) you probably want some for of automated packaging system, and you put the logic in there for specifying your version number (in the package meta data, in the name of the javascript file, which is typically the standard I've seen).
Take a look at sbt which is the Scala Build Tool. In it, we write dependencies like this:
val scalatest = "org.scalatest" %% "core" % "2.1.7" "test"
val jodatime = "org.joda" % "jodatime" % "1.4.5"
Wherein the operator %% means "the current version of Scala that you're building." Packaging things in this language generally create JAR files with the name like this <my project>_<scala version>_<library version>.jar which is quite handy for semantically naming things automagically. The % operator can be interpreted as "don't version this part."
That said, this resulted from the fact that the same library compiled to different Scala versions were not binary compatible with each other. So it was more as a result of, rather than a conscious design choice, the binary incompatibilities.
I've been tasked with maintaining an application originally written in VB6. It has since been imported into VB .Net and to say the least the code is anything but Object Oriented. The code is riddled with classes which contain nothing more than Public Shared attributes(variables) and methods(functions), the result of which restricts the application from opening more than one project at a time.
A project consists of a XML file which contains general project settings, as well as the location to an Access database which contains other project related data. Over the years the format of the XML file has been modified, and an update and versioning strategy has been adopted. The chosen strategy performs an update upon open whenever an old version is encountered. Thus far, updates have only consisted of rearranging data within the XML file or making database schema changes and moving data from the XML file to the database.
Having quite a bit of background in OOP it's easy for me to see that a project should be a self contained object which other objects interact with. However, I fail to see how to apply the chosen update strategy in OOP.
The problem of implementing the chosen update strategy in OOP has kept me from using OOP as of yet. If anyone has experience with such a task, or recommendations on how to proceeded I'd appreciate any assistance you can provide.
Build a class which reads the XML file in, and provides properties/methods/etc based upon the data in that file. When the class writes the XML file back out, have it format in the manner needed for the new version.
So, basically, the class will be able to read in the current version, plus all the older versions, but it will always write out the new version.
Data would be held in internal variables of the class, rather than having to scan the XML file every time you need something.
Adding a VERSION node to your XML file will also help in this case.
You might have answered your own question when you used the word strategy (i.e. the Strategy Design Pattern).
Possibly you could:
Create a project class that knows nothing about conversions but accepts a strategy object.
Create a hierarchy of classes to model each possible conversion strategy.
Use a factory method to build your project object with the right strategy
I don't understand why this is a troubling problem. It could be solved in any number of ways.
If you want to do a full object oriented enterprisey type thing, you could take any subset of the following solution:
Create an interface IProject which
describes how other objects interact
with a project.
Create the current implementation of
Project which implements IProject
and can read and write to the
current version.
Extend Project for each past
version, overriding the xml and
database read methods and having the
constructor call write when these
classes are instanced
For extra enterpriseyness, create a
ProjectFactory, which detects the
version of the file and instanciates
the correct version.
If further versions are needed,
rewrite the current Project to do
the same thing as past projects,
accessing the new version of Project
with all the reads and then calling
write.
The advantage of this solution is that you can continue meandering about with different versions and each new version only requires the ability to be updated to from the previous version, with all previous versions cascading up to the second to last version.