I'm using HiQPdf to merge 2 pdf in one file, following to the official help: https://www.hiqpdf.com/documentation/html/e5d2f1ee-dccb-4351-888e-e3f3c15a93a5.htm
I get the "HiQPdf Evaluation". Which prove the code works.
I added my serial number:
PdfDocument resultDocument = new PdfDocument();
resultDocument.SerialNumber = "AU***************-OA=="; // this line is not in the help
PdfDocument document1 = PdfDocument.FromFile("c:\\temp\\doc1.pdf);
resultDocument.AddDocument(document1);
PdfDocument document2 = PdfDocument.FromFile("c:\\temp\\doc2.pdf);
resultDocument.AddDocument(document2);
resultDocument.WriteToFile("c:\\temp\\MergePdf.pdf"); //getting an Exception here !
I get an exception on the resultDocument.WriteToFile : Cannot write the document to output file. Invalid Serial Number Version.
If I remove the resultDocument.SerialNumber, the merged pdf is generated but with the "HiQPdf Evaluation" water mark.
I assert that my serial is correct since I succesfully use it to for HtmlToPdf conversion:
HtmlToPdf htmlToPdfConverter = new HtmlToPdf();
htmlToPdfConverter.SerialNumber = "AU***************-OA==";
PdfDocument resultDoc = null;
resultDoc = htmlToPdfConverter.ConvertHtmlToPdfDocument(html, "");
This code (with my serial) succesfully produces a PDF without the "HiQPdf Evaluation: water mark. And if I remove my serial, the "HiQPdf Evaluation: water mark appears.
Is there another place/way to use the serial? Is it possible that my Serial is correct for htmlToPdfConverter but not the PdfDocument merging?
I finally received a response from the support: my serial is valid for a PREVIOUS version of HiQPdf.
Be aware that in Nuget, the only version available is version 12. To downgrade you need to find a backup of your previous version of HiQPdf.dll and put it manually in you packages.
Below the response from the support:
HiQPdf Sales sales#hiqpdf.com Mon 18/04/2022 18:20
Hello,
Your serial number is for version 10 of the software. For version 12
you need a new serial number.
You can renew the old license with a 20% renewal discount to obtain a
serial number for the latest version of the software in the page
below: [link removed]
Best Regards,
Jacob
Related
I'm working on trying to use ligands that are referenced in UniProt with the same ligand in PDB entries. For many ligands (e.g. FAD), the three-letter code is the same in both UniProt and PDB entries, but for some there is a slight difference. For example, for haemoglobin 1a9w chain A, in the PDB file I find "HEM" but in the corresponding UniProt entry (P69905) I find "heme b". "heme b" (in the UniProt json) has chebi id CHEBI:60344.
I downloaded the full ChEBI sdf file from https://ftp.ebi.ac.uk/pub/databases/chebi/SDF/, and find there are three haems that are close to what I want. So far, so good.
If I use the following code to calculate Tanimoto coefficients using CHEBI:60344 as a reference, one of the haems is okay but the other raises a C++ exception that I haven't been able to catch in my Python code. The problem is that if my list of chebi ids is the other way round, the code always fails before I get a value for the Tanimoto coefficient.
My question is - is this a bug in my implementation of the RDKIT code, is it a bug in the RDKIT code, is it a bug in the ChEBI module of bioservices, is the SMILES string in the ChEBI sdf file written incorrectly, or is there another issue?
This is all using conda installed rdkit, bioservices, python3.9 etc on a (old) Mac Pro running High Sierra (can't upgrade to a newer OS).
Ran this code:
from rdkit import Chem, DataStructs
from bioservices import ChEBI
heme = ChEBI()
heme_chebi_id = "CHEBI:60344"
heme_smiles = heme.getCompleteEntity(heme_chebi_id).smiles
target = Chem.MolFromSmiles(heme_smiles)
fp2 = Chem.RDKFingerprint(target)
for chebi_id in ["CHEBI:17627", "CHEBI:26355"]:
ch = ChEBI()
smiley = ch.getCompleteEntity(chebi_id).smiles
print("reference:", heme_chebi_id)
print("target: ", chebi_id)
print("reference:", heme_smiles)
print("target: ", smiley)
ref = Chem.MolFromSmiles(smiley)
fp1 = Chem.RDKFingerprint(ref)
Tan = DataStructs.TanimotoSimilarity(fp1, fp2)
print(Tan)
print("-" * 64)
exit()
got this output:
reference: CHEBI:60344
target: CHEBI:17627
reference: CC1=C(CCC([O-])=O)C2=[N+]3C1=Cc1c(C)c(C=C)c4C=C5C(C)=C(C=C)C6=[N+]5[Fe--]3(n14)n1c(=C6)c(C)c(CCC([O-])=O)c1=C2
target: CC1=C(CCC(O)=O)C2=[N+]3C1=Cc1c(C)c(C=C)c4C=C5C(C)=C(C=C)C6=[N+]5[Fe--]3(n14)n1c(=C6)c(C)c(CCC(O)=O)c1=C2
Tanimoto coefficient: 1.0
reference: CHEBI:60344
target: CHEBI:26355
reference: CC1=C(CCC([O-])=O)C2=[N+]3C1=Cc1c(C)c(C=C)c4C=C5C(C)=C(C=C)C6=[N+]5[Fe--]3(n14)n1c(=C6)c(C)c(CCC([O-])=O)c1=C2
target: CC1=C(CCC(O)=O)C2=[N]3C1=Cc1c(C)c(C=C)c4C=C5C(C)=C(C=C)C6=[N]5[Fe]3(n14)n1c(=C6)c(C)c(CCC(O)=O)c1=C2
[12:36:26] Explicit valence for atom # 9 N, 4, is greater than permitted
Traceback (most recent call last):
File "/Volumes/Users/harry/icl/phyre2-ligand/./tanimoto_test.py", line 20, in <module>
fp1 = Chem.RDKFingerprint(ref)
Boost.Python.ArgumentError: Python argument types in
rdkit.Chem.rdmolops.RDKFingerprint(NoneType)
did not match C++ signature:
RDKFingerprint(RDKit::ROMol mol, unsigned int minPath=1, unsigned int maxPath=7, unsigned int fpSize=2048, unsigned int nBitsPerHash=2, bool useHs=True, double tgtDensity=0.0, unsigned int minSize=128, bool branchedPaths=True, bool useBondOrder=True, boost::python::api::object atomInvariants=0, boost::python::api::object fromAtoms=0, boost::python::api::object atomBits=None, boost::python::api::object bitInfo=None)
This error means that the input to the function Chem.RDKFingerprint is None. That means that ref is None. You can try printing the value of ref to verify.
In this case, this is None because RdKit is not able to parse the given SMILES to a proper mol object. It has even raised the following warning if you look at the error carefully:
Explicit valence for atom # 9 N, 4, is greater than permitted
This is because of the co-ordinate bond present in the molecule which RdKit doesn't support. RdKit will treat it as a single bond which will raise the valency of both the Nitrogen atoms to 4 and hence an invalid molecule. Here's the same molecule generated from other sources:
To deal with this error, you'll have to modify the SMILES manually to make it such that either there's a charge on those nitrogen atoms or [Fe] is a separate atom rather than connected with a bond. Something like this:
This isn't really an issue with the SMILES but more of a limitation with RDKit for its inability to support co-ordinate bonds. I have faced this issue many times and always had to modify the SMILES manually to get around it. One suggestion for you is that you can programmatically modify the SMILES because this kind of error will most likely occur for Metal-Ligand catalysts where a co-ordinate bond is almost always there. So you can search for atoms like [Fe] or [Pt] in the SMILES string and then modify them.
I've managed to get a couple of workarounds for this.
The problem arises because RDKit is (as of 30 Jan 2023) unable to process some IUPAC compliant SMILES (as noted in betelgeuse's answers).
One thing to do is to use the "Sanitize=False" option for rdkit.Chem.MolFromSmiles - this allows a non-None value to be returned for this SMILES, and subsequently, rdkit.Chem.RDKFingerprint returns a useful value.
However, using the results of the "Sanitize=False" option fails if I want to explore an alternative measure of similarity, e.g. FCFP4 instead of Tanimoto, using "rdkit.Chem.rdMolDescriptors.GetMorganFingerprint"; the way I got round this was to test for "None" from MolFromSmiles without using sanitize=False, retrieve an alternative SMILES from PubChem and use that. Having said that, if I didn't really want the SMILES from PDBeChem, I could have done that in the first place...
When I import product data or I upload image directly to a product I get the following message (was not uploaded. Filename is too long; must be 90 characters or less)
Recently my magento has been updated and I didn't have this problem before.
Does anyone know how I can increase the number of characters slightly?
enter image description here
I was able to solve the problem myself.
The file in question is located in the following folder
vendor\magento\framework\File Uploader.php
search for the following code:
// account for excessively long filenames that cannot be stored completely in database
if (strlen($fileInfo['basename']) > 90) {
throw new \InvalidArgumentException('Filename is too long; must be 90 characters or less');
Adjusting this file is not the best method, I have to add
For anyone finding this question on Google, I wanted to share additional findings, as I've faced the same issue. Perhaps you will find them helpful.
As #Timo already wrote, the limit of 90 characters is hard-coded in the getCorrectFileName() method in vendor\magento\framework\File\Uploader.php (in older versions of Magento).
public static function getCorrectFileName($fileName)
{
(...)
$maxFilenameLength = 90;
if (strlen($fileInfo['basename']) > $maxFilenameLength) {
throw new \LengthException(
__('Filename is too long; must be %1 characters or less', $maxFilenameLength)
);
}
(...)
}
Since this method is static, writing a plugin is not possible and apparently providing a preference won't work as well.
It seems that there was a fix for this already available in Magento, but only in versions 2.4.2 and 2.4.2-p1. Then, for whatever reasons it got removed. See the related Github issue.
Since Magento v2.4.5 the file name length is now limited to 255 characters:
private const MAX_FILE_NAME_LENGTH = 255;
(...)
public static function getCorrectFileName($fileName)
{
(...)
if (strlen($fileInfo['basename'] ?? '') > self::MAX_FILE_NAME_LENGTH) {
throw new \LengthException(
__('Filename is too long; must be %1 characters or less', self::MAX_FILE_NAME_LENGTH)
);
}
(...)
}
So, until you upgrade your Magento version to 2.4.5 or newer, it seems that making a change in the core code is the only option, either manually or using a composer patch.
/Users/Barry/anaconda/lib/python2.7/site-packages/gensim/models/ldaseqmodel.py:217: RuntimeWarning: divide by zero encountered in double_scalars
convergence = np.fabs((bound - old_bound) / old_bound)
#dynamic topic model
def run_dtm(num_topics=18):
docs, years, titles = preprocessing(datasetType=2)
#resort document by years
Z = zip(years, docs)
Z = sorted(Z, reverse=False)
years_new, docs_new = zip(*Z)
#generate time slice
time_slice = Counter(years_new).values()
for year in Counter(years_new):
print year,' --- ',Counter(years_new)[year]
print '********* data set loaded ********'
dictionary = corpora.Dictionary(docs_new)
corpus = [dictionary.doc2bow(text) for text in docs_new]
print '********* train lda seq model ********'
ldaseq = ldaseqmodel.LdaSeqModel(corpus=corpus, id2word=dictionary, time_slice=time_slice, num_topics=num_topics)
print '********* lda seq model done ********'
ldaseq.print_topics(time=1)
Hey guys, I'm using the dynamic topic models in gensim package for topic analysis, following this tutorial, https://github.com/RaRe-Technologies/gensim/blob/develop/docs/notebooks/ldaseqmodel.ipynb, however I always got the same unexpected error. Can anyone give me some guidance? I'm really puzzled even thought I have tried some different dataset for generating corpus and dictionary.
The error is like this:
/Users/Barry/anaconda/lib/python2.7/site-packages/gensim/models/ldaseqmodel.py:217: RuntimeWarning: divide by zero encountered in double_scalars
convergence = np.fabs((bound - old_bound) / old_bound)
The np.fabs error means it is encountering an error with NumPy. What NumPy and gensim versions are you using?
NumPy no longer supports Python 2.7, and Ldaseq was added to Gensim in 2016, so you might just not have a compatible version available. If you are recoding a Python 3+ tutorial to a 2.7 variant, you obviously understand a little bit about the version differences - try running it in a, say, 3.6.8 environment (you will have to upgrade sometime anyway, 2020 is the end of 2.7 support from Python itself). That might already help, I've gone through the tutorial and did not encounter this with my own data.
That being said, I have encountered the same error before when running LdaMulticore, and it was caused by an empty corpus.
Instead of running your code fully in a function, can you try to go through it line by line (or look at you DEBUG level log) and check whether your output has the expected properties: that, for example your corpus is not empty (or contains empty documents)?
If that happens, fix the preprocessing steps and try again - that at least helped me and helped with the same ldamodel error in the mailing list.
PS: not commenting because I lack the reputation, feel free to edit this.
This is the issue with the source code of ldaseqmodel.py itself.
For the latest gensim package(version 3.8.3) I am getting the same error at line 293:
ldaseqmodel.py:293: RuntimeWarning: divide by zero encountered in double_scalars
convergence = np.fabs((bound - old_bound) / old_bound)
Now, if you go through the code you will see this:
enter image description here
You can see that here they divide the difference between bound and old_bound by the old_bound(which is also visible from the warning)
Now if you analyze further you will see that at line 263, the old_bound is initialized with zero and this is the main reason that you are getting this warning of divide by zero encountered.
enter image description here
For further information, I put a print statement at line 294:
print('bound = {}, old_bound = {}'.format(bound, old_bound))
The output I received is: enter image description here
So, in a single line you are getting this warning because of the source code of the package ldaseqmodel.py not because of any empty document. Although if you do not remove the empty documents from your corpus you will receive another warning. So I suggest if there are any empty documents in your corpus remove them and just ignore the above warning of division by zero.
I'm using iText® 5.2.1 ©2000-2012 1T3XT BVBA and Integration Designer 8.0 to create a PDF file that is exported in an byte array.
I am creating a document with a fair amount of text and want to add a logo at the beginning.
Part of the code that is adding the image is as follows:
BASE64Decoder decoder = new BASE64Decoder();
byte[] decodedBytes = decoder.decodeBuffer(Stringovi.SLIKA1);
Image image1 = Image.getInstance(decodedBytes);
image1.setAbsolutePosition(30f, 770f);
image1.scalePercent(60f);
document.add(image1);
The input image is in byte array format because of the system requirements.
The rest of the document consists of different tables with various content and it's all text.
When I add the image in the before mentioned way the program finishes and i get an byte output that i run trough a Base64 decoder. Resulting PDF can not be opend and the error shown is:
"Error [PDF Structure 40]:Invalid reference table (xref)"
I can't see where my mistake is so if anybody could be so kind and point me in the right direction I would very much appreciate it.
The document you presented as a "broken PDF file" is not a complete PDF file. It doesn't end with %%EOF, it doesn't have a cross-reference table,... It's a PDF document that isn't complete.
This means that you don't have the following line in your code:
document.close();
If you do have this line, it isn't reached. For instance: an exception is thrown causing the code to jump to a catch clause, skipping the close() operation.
The error message saying Invalid reference table (xref) is consistent with that diagnosis. This isn't a problem caused by iText. It's a problem caused by bad coding: not closing the document and/or not dealing with exceptions correctly.
I'm using iText to generate PDF files. I want to disallow editing of the PDF, but allow the reader to extract pages. Here's my code to set encryption:
writer.setEncryption(null, null, 0xffffffff, PdfWriter.STANDARD_ENCRYPTION_128);
The third parameter specifies permissions. I'm using 0xffffffff instead of the individual iText flags ALLOW_PRINTING etc. This will ask iText to enable everything. But this is what I get in the PDF file:
I should think I should be allowed to enable extraction but disable editing, but am not certain. Here are the permissions bits per Adobe:
(From here, but be warned it's 30 meg)
So turn off bits 6 and 11 but leave on the others (especially bits 5 and 10), and that would turn off editing but allow extraction. In any case, by specifying 0xffffffff I would think that everything would be allowed; but instead everything except extraction is allowed.
I've skimmed the iText source code for setting permissions and don't see anything that would cause this. Here is the relevant code from PdfEncryption.setupAllKeys:
permissions |= (revision == STANDARD_ENCRYPTION_128 || revision == AES_128 || revision == AES_256) ? 0xfffff0c0
: 0xffffffc0;
permissions &= 0xfffffffc;
The first line is doing an OR and so wouldn't remove any permissions; the second line is setting the two right-most bites to 0, per the PDF specification.
I'm wondering if it's an iText thing, a PDF thing or if I'm doing something else wrong.
Thanks
A similar issue already has been raised here.
Using encryption actually is counter-productive as it can only be used to remove permissions, not to add them.
According to this, it might be helpful to completely unlock the PDF first:
PdfReader reader = new PdfReader(file.toURI().toURL());
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream(
file.getAbsolutePath().replace(".pdf", "_UNLOCKED.pdf")));
stamper.close();
reader.close();
Afterwards you can grab the output and start from scratch (mess around with the permission bits). Hope this helps.
EDIT: If you don't have access to the password, the iText sources can be modified. Simply comment out if (!reader.isOpenedWithFullPermissions()) throw ... (line 121 and 122 in version 5.5.0) in com.itextpdf.text.pdf.PdfStamperImp.