I manage a blog where I use .svg files as illustrations, you can see a live example here: https://salarship.com/article/dress-fast-food-job-interview/
The problem is that the .svg files do not render properly on Firefox. Here is how the image looks on Firefox and how it looks on other browsers. Here is the raw file of the image: https://salarship.com/wp-content/uploads/2022/01/wear-job-interview-fast-food.svg
Is it a problem with this particular file, how can I fix it? I have hundreds of articles with this problem, is there a way to fix each image relatively quickly?
There is a path in there with the following command sequence (shortened for clarity):
... v 0 a 0.25,0.25 0 0 0 0,0.07 0.19,0.19 0 0 1 0,0.07 8.510071e11,8.510071e11 0 0 1 0,0.18 ...
The arc command with radius 8.510071e11 seems to throw Firefox. That is a bug.
since an arc with such a large radius is straight anyway, the sequence could be changed such that a v line command is used instead:
... v 0 a 0.25,0.25 0 0 0 0,0.07 0.19,0.19 0 0 1 0,0.07 v 0.18 ...
Related
I have the following code to download a torrent off of a magnet URI.
#python
#lt.storage_mode_t(0) ## tried this, didnt work
ses = lt.session()
params = { 'save_path': "/save/here"}
ses.listen_on(6881,6891)
ses.add_dht_router("router.utorrent.com", 6881)
#ses = lt.session()
link = "magnet:?xt=urn:btih:395603fa..hash..."
handle = lt.add_magnet_uri(ses, link, params)
while (not handle.has_metadata()):
time.sleep(1)
handle.pause () # got meta data paused, and set priority
handle.file_priority(0, 1)
handle.file_priority(1,0)
handle.file_priority(2,0)
print handle.file_priorities()
#output is [1,0,0]
#i checked no files written into disk yet.
handle.resume()
while (not handle.is_finished()):
time.sleep(1) #wait until download
It works, However in this specific torrent, there are 3 files, file 0 - 2 kb, file 1 - 300mb, file 3 - 2kb.
As can be seen from the code, file 0 has a priority of 1, while the rest has priority 0 (i.e. don't download).
The problem is that when the 0 file finishes downloading, i want to it to stop and not download anymore. but it will sometimes download 1 file -partially, sometimes 100mb, or 200mb, sometimes couple kb and sometimes the entire file.
So my question is: How can i make sure only file 0 is downloaded, and not 1 and 2.
EDIT: I added a check for whether i got metadata, then set priority and then resume it, however this still downloads the second file partially.
The reason this happens is because of the race between adding the torrent (which starts the download) and you setting the file priorities.
To avoid this you can set the file priorities along with adding the torrent, something like this:
p = parse_magnet_uri(link)
p['file_priorities'] = [1, 0, 0]
handle = ses.add_torrent(p)
UPDATE:
You don't need to know the number of files, it's OK to provide file priorities for more files than ends up being in the torrent file. The remaining ones will just be ignored. However, if you don't want to download anything (except for the metadata/.torrent) from the swarm, a better way is to set the flag_upload_mode flag. See documentation.
p = parse_magnet_uri(link)
p['flags'] |= add_torrent_params_flags_t.flag_upload_mode
handle = ses.add_torrent(p)
what I want is to add eps file into temporary ps file which has text written, then I convert my ps file to eps file using ghostscript, but when I see my eps file in AI outline mode, I see extra square around my eps file which is size box, which should not be there, It should be part of single compound box
Ghostscript version is 9.05 and before I include eps into ps I need to resize it. So resized eps file shows page border into outline mode. Which is actually not there, but when it goes to machine it will cut out that path which should not be case.
Alright, I think I have some understanding of what you're doing and where the trouble may be creeping in. As I commented, you're running the file through ghostscript multiple times. Each time it has to interpret the postscript code and construct an internal display-list representation and then recreate appropriate postscript code on the output end. So it's the clone of a clone of a clone problem. Any little hiccup can cause cascade failures.
So, enough of being preachy. The alternative is to manipulate the eps file as text.
So, if we want the image to be scaled to fill a 500x500 square, we will be guided by the number in the BoundingBox comment. I'll quote this silly file from the linked question as an example:
%!PS-Adobe-2.0 EPSF-2.0
%%BoundingBox: 72 700 127 708 %<-- modify this
%%HiResBoundingBox: 72.000000 700.000000 127.000000 707.500000 %<-- delete this
%%EndComments
% EPSF created by ps2eps 1.68
%%BeginProlog
save
countdictstack
mark
newpath
/showpage {} def
/setpagedevice {pop} def
%%EndProlog
%%Page 1 1 %<-- insert translate and scale after this line
/Times-Roman findfont
11 scalefont setfont
72 700 moveto
(This is a test)show
%%Trailer
cleartomark
countdictstack
exch sub { end } repeat
restore
%%EOF
So, the BoundingBox was %%BoundingBox: 72 700 127 708 and it needs to be 0 0 500 500 or rather (to preserve the aspect ratio) 0 0 x 500 or 0 0 500 y where x or y (whichever it happens to be) is < 500. The existing size is 127-72 x 708 - 700 = 55 x 8. So our scaling factor is 500/55. But we also want to translate the lower-left corner to the origin, and its simplest to do that first, so the scaling doesn't affect the interpretation of the numbers.
So, to take 72 700 127 708 to 0 0 500 y, first we add -72 -700 translate to the file, and modify the bounding box to 0 0 55 8, and delete that silly HiRes line: we don't really need it.
Then, we add 500 55 div dup scale (let the interpreter do the math, hee hee). So the maximum x will now be 500, but, oh, what to put for the y? A quick calculation yields 72!
So, this awk program will modify an eps file to be 500 points wide, with y scaled appropriately.
/%%BoundingBox: ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*)/{x=$2;y=$3;w=$4-x;h=$5-y;print $1,0,0,500,(500/w)*h}
!/%%BoundingBox:/&&!/%%HiRes/{print}
/%%Page /{print -x,-y,"translate"; print 500,w,"div dup scale"}
Usage:
$ awk -f epsscale.awk etest.eps
EDIT: mftraining gives the warning in the title for all the characters in the unicharset (so not just F, but a, b, c, d, etc also) How do I create these protos/configs?
I'm following this tutorial
Previous question that is now solved:-
Error:Assert failedWarning:in file ....\classify\trainingsampleset.cpp, line 622 no protos/ Segmentation Fault
This is the entire command + output:-
C:\training>mftraining -F font_properties -U unicharset -O eng.unicharset eng.impact.box.tr Warning: No shape table file present: shapetable Reading eng.impact.box.tr ... Font id = -1/0, class id = 1/103 on sample 0 font_id >= 0 && font_id < font_id_map_.SparseSize():Error:Assert failed:in file....\classify\trainingsampleset.cpp, line 622
I've looked through everything I could find on this warning in the title for all the characters in the unicharset (which wasn't much as it is)so not just F, but a, b, c, d, etc also) How do I can't figure out what the problem is and what would make it work. create these protos/configs?
I also tried the shapeclustering command, but that gives me the same error.
Also, when I run these on cygwin, it displays Segmentation Fault instead of the assertion error.
I was having the same problem, and it was indeed a problem with font_properties. However, in my case, it was solved by making sure that the font in font_properties matched exactly the font name in the .tr file. In my case, that was [fontname].exp0.
I have the same problem with you.
And It's because the font_properties is not formatted right.
Each line of the font_properties file is formatted as follows:
fontname italic bold fixed serif fraktur
here only the fontname is needed.
when I changed the file from lang.fontname.exp0 0 0 0 0 0 to fontname 0 0 0 0 0, my problem fixed
I have found two possible causes of this problem.
Possible cause 1: incorrect font_properties
The font_properties file should contain the content described at:
https://github.com/tesseract-ocr/tesseract/wiki/Training-Tesseract-3.00%E2%80%933.02#font_properties-new-in-301
and the file encoding should met the requirements of:
https://github.com/tesseract-ocr/tesseract/wiki/Training-Tesseract-3.00%E2%80%933.02#requirements-for-text-input-files
This is the most common answer on the Internet.
(Also make sure you specify the font in font_properties and not the language.)
Possible cause 2: wrong training file name
However I found that trying to fix font_properties didn't work for me, and discovered another cause that gave the same error in my case.
The file .tr files must contain the following format:
<language>.<fontname>.exp<num>.tr
and not:
<language>.<fontname>.exp<num>.box.tr
(as is seen in some tutorials)
So in my case, this will NOT work:
tesseract eng.unknown.exp1.png eng.unknown.exp1.box nobatch box.train
unicharset_extractor eng.unknown.exp1.box
mftraining -F font_properties -U unicharset -O eng.unicharset eng.unknown.exp1.box.tr
whereas this small change does work:
tesseract eng.unknown.exp1.png eng.unknown.exp1 nobatch box.train
unicharset_extractor eng.unknown.exp1.box
mftraining -F font_properties -U unicharset -O eng.unicharset eng.unknown.exp1.tr
You misses a shapeclustering step, which is new in Tesseract 3.02 training.
I had the same issue and changing
fontname 0 0 0 0 0
to
fontname.exp0 0 0 0 0 0
according to the fontname in the .tr file fixed it
I had the same issue, and changing font_properties as following fixed it:
from -
batangche 1 0 0 0 0
to -
batangche.exp0 1 0 0 0 0
In my case the font name in the font_properties file was uppercase, where the font name in the .tr file was lowercase. Changing them to the same case solved the problem.
I want to write a bin file to a flash drive. I'm supposed to run:
n helloworld.bin
l 0
w 0 0 0 1
But when I run l 0 I get a File not found error. What am I doing wrong?
Two issues:
MS-DOS filenames should have a maximum of 8 letters before the dot and a maximum of 3 letters after the dot.
For this use of the l command in debug, provide no parameters. The file will always be loaded to CS:0100.
(I somehow find it worrying that my brain saved this useless information for all those years...)
I am using wkhtmltopdf to generate a PDF file that is going to a printer and have some troubles with making the content fill up an entire page in the resulting PDF.
In the CSS I've set the width and height to 2480 X 3508 pixels (a4 300 dpi) and when creating the PDF I use 0 for margins but still end up with a small white border to the right and bottom. Also tried to use mm and percentage but with the same result.
I'd need someone to please provide an example on how to style the HTML and what options to use at command line so that the resulting PDF pages fill out the entire background. One way might be to include bleeding (this might be necessary anyway) but any tips are welcome. At the moment I am creating one big HTML page (without CSS page breaks - might help?) but if needed it would be fine to generate each page separately and then feed them all to wkhtmltopdf.
wkhtmltopdf v 0.11.0 rc2
What ended up working:
wkhtmltopdf --margin-top 0 --margin-bottom 0 --margin-left 0 --margin-right 0 <url> <output>
shortens to
wkhtmltopdf -T 0 -B 0 -L 0 -R 0 <url> <output>
Using html from stdin (Note dash)
echo "<h1>Testing Some Html</h2>" | wkhtmltopdf -T 0 -B 0 -L 0 -R 0 - <output>
Using html from stdin to stdout
echo "Testing Some Html" | wkhtmltopdf -T 0 -B 0 -L 0 -R 0 - test.pdf
echo "Testing Some Html" | wkhtmltopdf -T 0 -B 0 -L 0 -R 0 - - > test.pdf
What did not work:
Using --dpi
Using --page-width and --page-height
Using --zoom
We just solved the same problem by using the --disable-smart-shrinking option.
I realize this is old and cold, but just in case someone finds this and has the same/similar problem, here's a workaround that worked for me after some trial&error.
I created a simple filler.html as:
<!DOCTYPE html>
<html>
<head>
</head>
<body style="margin: 0; padding: 0;">
<div style="height: 30mm; background-color: #F7EBD4;">
</div>
</body>
</html>
Use valid HTML (!DOCTYPE is important) and only inline styles. Match the background color to that of the main document and use height equal or bigger than your margins.
I run version 0.12.0 with the following arguments:
wkhtmltopdf --print-media-type --orientation portrait --page-size A4
--encoding UTF-8 --T 10mm --B 10mm --L 0mm --R 0mm
--header-html filler.html --footer-html filler.html - - <file.html >file.pdf
Hoping this helps someone...
I'm using version 0.12.2.1 and setting:
body { padding: 0; margin 0; }
div.page-layout { height: 295.5mm; width: 209mm;}
worked for me.
Of course need to add 0 margins by:
wkhtmltopdf -T 0 -B 0 -L 0 -R 0
At http://code.google.com/p/wkhtmltopdf/issues/detail?id=359 I found out more people 'suffer' from this bug. The --dpi 300 workaround did not work for me, I had to set --zoom 1.045 to zoom in a bit which made the extra right and bottom border disappear...
Works fine for me with -B 0 -L 0 -R 0 -T 0 options and using your trick of setting up an A4 sized div.
Did you remember to use body {margin:0; padding:0;} in the top of your CSS?
I cannot help you with CSS page breaks as I have not trialled an errored those yet, however, you can run scripts on the page to do clever things. Here is a jQuery example of how to split content down into page size chunks based on the length of the content. If you can get that adapted to work with wkhtmltopdf then please post here!
http://www.script-tutorials.com/demos/79/index.html
What you are experiencing is a bug.
You'll need to set the --dpi option when converting the file. In you case you will probably want --dpi 300, but that can be set lower.
Solved it by increasing the DPI
I'm working with an A4 size in portrait mode. Had white space to the right.
I noticed that as the dpi is increased, the white space got thinner.
at 300 dpi the white space is not visible in chrome pdf view at (max) zoomed at 500%
In Adobe reader it's still visible. It got better at 600 DPI and at 1200 DPI it's become invisible even at 6500% zoom.
There's no disadvantage to this so far as I observed, all dpi generate the same file size and run at the same speed (tested on 1 page).
effectively my settings are as follows:
echo "<html style='padding=0;margin=0'><body style='background-color:black;padding=0;margin=0'></html>" | wkhtmltopdf -T 0 -B 0 -L 0 -R 0 --disable-smart-shrinking --orientation portrait --page-size A4 --dpi 1200 - happy.pdf
If using an unscaled PNG image (thus will be pixel perfect) the default ratio, for an A4 needs to be 120ppi thus # 210mm = 993 pixels wide x 1404 pixels high, if the source is 72 or 300 dpi it makes no difference for a default placement, its the 993 that's counted as 210 mm
No heights, no width, no stretch, nor shrink just default place image as background un-scaled.
wkhtmltopdf --enable-local-file-access -T "0mm" -L "0mm" -R "0mm" -B "0mm" test.html test.pdf
here is such an image reduced into A 4 pdf page 2 different densities same number of pixels
If you use scaling you can use different density values, but this is all that is needed by default's, since PDF works on overall pixel values not DPI as such. Note the PNG is actually smaller by insertion in a PDF than the source JPG which was over 372 KB