On iOS, in both Chrome and Firefox, saving a blob to a file, using the technique of embedding an object URL in a hidden link in the DOM and programmatically clicking on it, does not work. The following happens:
JSON (blob of type application/json) displays the JSON in plain text
but does not download it.
An XLSX spreadsheet (blob of type
application/octet-stream) does nothing.
PNG (blob of type image/png)
displays the image but does not download it.
SVG (blob of type
image/svg+xml) displays the image but does not download it.
The download technique works on iOS Safari as well as all the following desktop browsers: Chrome, Firefox, Safari and Edge.
Here is the code:
const blobURL = URL.createObjectURL(blob);
const tempLink = document.createElement("a");
tempLink.style.display = "none";
tempLink.href = blobURL;
tempLink.setAttribute("download", filename);
tempLink.setAttribute("target", "_blank");
document.body.appendChild(tempLink);
tempLink.click();
tempLink.remove();
URL.revokeObjectURL(blobURL);
What can I do to enable the user to download data created in the browser on iOS Chrome and Firefox?
I try to build an app that let's users select rectangles on a google Map. The coordinates should than be extracted and used for further calculations. I found an excellent tutorial here on how to interact with the google api and send the data to R. However, I needed to modify the files a bit to have a costum ui.R that lets the user select the fields but also select other options important for processing.
So now I have three files in the same directory.
The html file with the javascript commands for the google api, the ui.R and the server.R.
index.html
content can be found in the link above but the important part is:
//This function listen to the drawing manager and after you draw the rectangle it extract the coordinates of the NE and SW corners
google.maps.event.addListener(drawingManager, 'rectanglecomplete', function(rectangle) {
var ne = rectangle.getBounds().getNorthEast();
var sw = rectangle.getBounds().getSouthWest();
//The following code is used to import the coordinates of the NE and SW corners of the rectangle into R
Shiny.onInputChange("NE1", ne.lat());
Shiny.onInputChange("NE2", ne.lng());
Shiny.onInputChange("SW1", sw.lat());
Shiny.onInputChange("SW2", sw.lng());
ui.R
I use tags$embed to embed the index.html file in ui.R
require(shiny)
shinyUI(
fluidPage(
titlePanel("Included Content"),
# mainPanel(
fluidRow(
column(9,
div(style='height:800px; width:1200px; overflow: hidden',
tags$embed(src="./index.html", seamless=FALSE,width="100%",height="100%"))),
column(3,
h2("Some Calculations"),
selectInput("Test",label=NA,choices=c("yes","no")),
selectInput("Test2",label=NA,choices=c("2","3")),
h3("Coordinates"),
tableOutput("test"),
h3("allInput"),
tableOutput("test2"))
)
))
server.R
# server.R
library(sp)
library(rjson)
library(shiny)
library(dplyr)
library(tidyr)
shinyServer(function(input, output,session) {
CorLongLat<<-reactive({
if(length(input$NE1)>0){
as.data.frame(matrix(c(input$NE2,input$NE1,input$NE2,input$SW1,input$SW2,input$SW1,input$SW2,input$NE1),ncol=2,byrow=T))
}
})
output$test<-renderTable({
CorLongLat()
})
output$test2<-renderTable({
as.data.frame(reactiveValuesToList(input))%>%gather(ID,Value)
})
})
However, if I try to disply all inputs via output$test2<-renderTable({
as.data.frame(reactiveValuesToList(input))%>%gather(ID,Value)
})
it showes only the controls that are directly embeded in the ui.R. How do I access the variables NE1,NE2,SW1,SW2 from index.html that are created via Shiny.onInputChange?
EDIT
In the meantime I got a little closer to the core of the problem. Running the App with options(shiny.trace=TRUE) tells me after launching the app the following
Listening on http://127.0.0.1:4840
SEND {"config":{"workerId":"","sessionId":"16000363ddc17409cd5fdf25c038b61d"}}
RECV {"method":"init","data":{"Test":"yes","Test2":"2",".clientdata_output_test4_hidden":false,".clientdata_pixelratio":1,".clientdata_url_protocol":"http:",".clientdata_url_hostname":"127.0.0.1",".clientdata_url_port":"4840",".clientdata_url_pathname":"/",".clientdata_url_search":"",".clientdata_url_hash_initial":"",".clientdata_singletons":"",".clientdata_allowDataUriScheme":true}}
SEND {"errors":[],"values":[],"inputMessages":[]}
SEND {"config":{"workerId":"","sessionId":"0881062c26c882de2d0648a96ed98296"}}
RECV {"method":"init","data":{".clientdata_output_json_hidden":false,".clientdata_pixelratio":1,".clientdata_url_protocol":"http:",".clientdata_url_hostname":"127.0.0.1",".clientdata_url_port":"4840",".clientdata_url_pathname":"/index.html",".clientdata_url_search":"",".clientdata_url_hash_initial":"",".clientdata_singletons":"",".clientdata_allowDataUriScheme":true}}
SEND {"errors":[],"values":[],"inputMessages":[]}
After selecting a triangle on the map I get
RECV {"method":"update","data":{"NE1":67.40748724648756,"NE2":-11.77734375,"SW1":62.552856958572896,"SW2":-26.9384765625}}
And after selecting on selectInput :
RECV {"method":"update","data":{"Test2":"3"}}
I think the problem here is the second sessionID that is established. How do I refer to those in server.R or how do I combine both into on?
I'm converting a Dart app that uses the GMap lib to Polymer. The map however does not seem to get rendered and nothing else of my app is as well. All I get is a blank screen. I'm not getting a runtime error.
The div where the map is rendered in is in a polymer element. In the Dart file, I'm instantiating the map like this:
final mapOptions = new MapOptions()
..zoom = 15
..center = LAT_LONG_KORTRIJK
..mapTypeId = MapTypeId.ROADMAP;
Element mapView = getShadowRoot("my-element").query("#mapView");
_map = js.retain(new GMap(mapView, mapOptions));
Any ideas on what be going on?
The js package does not support Shadow DOM for now. You are facing to issue-99. Until a native Element support in dart:js lands I don't think this issue will be fixed.
Danger Zone : There could perhaps be a dirty way to work around this problem based on this message by manually replacing /packages/js/ with the content of the pointed js branch.
My iPad app pops the Google Earth app via UIApplication:openURL: and passes it a URL of a file to display. The file displays fine, except for Camera and LookAt tags. It seems that the Camera tag is totally disregarded, while the LookAt is partially processed such that the point of view moves to a point close to the ground, much lower than the LookAt specification.
To debug this, I created two KMLs, copied from Google's documentation. The content is generated by a query on my server. The query's URL is passed to the Google Earth app from my app.
For comparison, I opened the same data on Google Earth running on a Mac. It works fine there.
This file is treated as a no-op by GE - it does not move its point of view at all:
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Placemark>
<Camera>
<longitude>-122.4783</longitude>
<latitude>37.8120</latitude>
<altitude>100</altitude>
<heading>90</heading>
<tilt>90</tilt>
<altitudeMode>absolute</altitudeMode>
</Camera>
</Placemark>
</Document>
</kml>
The following does move the point of view to the general area, but to a point which is exactly 500 meters above the ground, regardless of the range value.
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Placemark>
<name>Machu Picchu, Peru</name>
<LookAt>
<longitude>-72.503364</longitude>
<latitude>-13.209676</latitude>
<altitude>0</altitude>
<range>14794.882995</range>
<tilt>66.768762</tilt>
<heading>71.131493</heading>
</LookAt>
<styleUrl>#msn_icon12</styleUrl>
<Point>
<coordinates>-72.516244,-13.162806,0</coordinates>
</Point>
</Placemark>
</Document>
</kml>
I am using Google Earth 7.0.0.7455 on the iPad.
Any other tag that I passed to the GE app, such as for drawing polygons, works just fine. I'm only having trouble with Camera and LookAt.
I wonder if it's my bug, Google's, or both. If Google's, is there a workaround - any way of setting the camera?
I am using ABCPDF to print a PDF file to a local printer via EMF file. I've based this very closely on ABC PDF's sample "ABCPDFView" project. My application worked fine on my Windows 7 and Windows XP dev boxes, but when I moved to a Windows 2003 test box, simple embedded fonts (like Times New Roman 12) rendered completely wrong (wrong spot, and short and squat, almost like the DPI's were crazily wrong).
Note that I've hardcoded the DPI to 240 here b/c I'm using a weird mainframe print driver that forces 240x240. I can discount that driver as the culprit as, if I save the EMF file locally during print, it shows the same layout problems. If I render to PNG or TIFF files, this looks just fine on all my servers using this same code (put .png in place of .emf). Finally, if I use the ABCPDFView project to manually add in a random text box to my PDF, that text also renders wrong in the EMF file. (Side note, if I print the PDF using Acrobat, the text renders just fine)
Update: I left out a useful point for anyone else having this problem. I can work around the problem by setting RenderTextAsText to "0" (see code below). This forces ABCPDF to render the text as polygons and makes the problem go away. This isn't a great solution though, as it greatly increases the size of my EMF files, and those polygons don't render nearly as cleanly in my final print document.
Anyone have any thoughts on the causes of this weird font problem?
private void DoPrintPage(object sender, PrintPageEventArgs e)
{
using (Graphics g = e.Graphics)
{
//... omitted code to determine the rect, used straight from ABC PDF sample
mDoc.Rendering.DotsPerInch = 240 ;
mDoc.Rendering.ColorSpace = "RGB";
mDoc.Rendering.BitsPerChannel = 8;
mDoc.SetInfo(0, "RenderTextAsText", "0");//the magic is right here
byte[] theData = mDoc.Rendering.GetData(".emf");
using (MemoryStream theStream = new MemoryStream(theData))
{
using (Metafile theEMF = new Metafile(theStream))
{
g.DrawImage(theEMF, theRect);
}
}
//... omitted code to move to the next page
}
Try upgrading to the new version of abcpdf 8, it has its own rendering engine based on Gecko and so you can bypass issues like this when abcpdf is using the inbuilt server version of IE for rendering.
I was originally RDPing in with 1920x1080 resolution, by switching to 1024x768 res for RDP, the problem went away. My main program runs as a service, and starting this service from an RDP session w/ 1024x768 fixes it.
I have an email out w/ ABC PDF to see if they can explain this and offer a more elegant solution, but for now this works.
Please note that this is ABC PDF 7, I have no idea if this issue applies to other versions.
Update: ABC PDF support confirmed that its possible the service is caching the display resolution from the person that started the process. They confirmed that they've seen some other weird issues with Remote Desktop and encouraged me to use this 1024x768 workaround and/or start the service remotely.