I'm started to read RFC2045 which reffered to very old RFC822. So what is actual RFC version of Internet Message Format and MIME?
RFC5322 obsoleted RFC2822, which already obsoleted RFC822. RFC822 is too old and only kept to find the exact information when referred to elsewhere. You can find the same information, more up to date, in RFC5322.
When some text refers to obsoleted RFCs, you can find the same information in the newer one that obsoletes the older one. The only obstacle there is that you will have to do additional text-search, because the text-structure is not kept between RFCs. Only if you can't find the information you are looking for in the newer RFC, then you should look into the older, obsoleted one.
Related
There is for example a DatePicker and a Calendar control in the main package (office-ui-fabric-react) and in the date-time package as well (installed as #uifabric/date-time). Both APIs seem to be nearly identical, but differ in some properties. For example in Calendar the calendarDayProps property (requested in this issue) is missing in the main package, but only available in the date-time package. I only found this out by searching through the github issues, because there is no official documentation available for the date-time package. The documentation page available only refers to the main package version.
On the other hand, in the already closed issue, it is nowhere mentioned, that this fix only applies to the date-time package version, as if this should be clear somehow. I feel that I missed some information.
So what's the point here? Will the date-time package version at some point in time replace the main package version? Are they intended to be used interchangeably? Why is there no documentation on this? I'm really confused ...
I see an Elf file may contains version sections like .gnu.version (readelf -V to display thire contents). What is the meaning of these information? Is there any documentation about version sections?
I'm afraid the most complete piece of documentation is Ulrich Drepper's notes however stale/incomplete they are. You can also get some inspiration from Solaris docs (Linux dynamic linking is a shameles^W copy of Solaris after all).
Many people have complained about lack of definitive documentation including Glibc maintainers themselves.
In addition to yugr's more implementation documentation, I have blogged about this a few times in the past, so you can look there for some "why and how to use" information.
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.
We are having a pdf which when opened in Acrobat Reader shows a version of 1.5 but when using Pdfbox(version 1.8.3) the version shows 1.3.
The code that we are using:
`aDocument.getDocument().getVersion()`
where aDocument is an instance of PDDocument.
Pdfbox version we are using is 1.8.3
Any help regarding this will be highly appreciated.
Hitesh Saliya already discussed that PDF in his question Adobe showing incorrect PDF Version (of PDF) in Properties. In this answer it became appearant that
version 1.3 was correct if one only takes the version header into account (there are no Version catalog entries in the document to consider);
at least version 1.5 was correct if one also took into account that object streams, cross reference streams, layers, and transparency are used.
In a way, therefore, both PDFBox and Adobe Reader are correct.
Thus, one first has to decide what one considers the version of a PDF document to be.
Is it the version the PDF file claims to be?
As a special case, what about PDFs claiming different versions? E.g. different entries in header and catalog, or different entries in different incremental updates.
Is it the version a chosen indicator program (e.g. Adobe Reader in a fixed version) recognizes for the PDF?
Is it the smallest / the largest version according to the respective PDF reference/specification the PDF is valid?
Could even any version in that range be a correct answer (resulting not in the version but the versions of a document)?
Some mixture of the above, e.g. the maximum of the version claimed and the lowest version according to which the PDF is valid?
Seriously, though, one can hardly expect anything more than option 1 to be implemented in a general purpose PDF library.
I want to know why Type 'iTextSharp.text.Table' is not defined. I already imported iTextSharp.text , iTextSharp.text.pdf, iTextSharp.text.html, iTextSharp.text.html.simpleparser.
Dim gvTable As New iTextSharp.text.Table(columns, tableRows)
In searching the Internet the only thing I could find about iTextSharp.Text.Table was example code. I looked at the SVN on SourceForge and there is no Table that is part of the text namespace, it looks like it was deprecated in the current version. Your best bet would be to use iTextSharp.text.pdf.PDFPTable. (Documentation from iText link) or to find a Version of iTextSharp previous to version 5. If you look at this SO Question/Answer there is a link to iTextSharp version 4.1.6 this version does have iTextSharp.text.Table. Here also is a blog that has links to the Source and dll.