Status Update
Comments
ze...@gmail.com <ze...@gmail.com> #2
Further testing points additional problems (which I guess are all the same problem) with the "copy()" function. The issue is that even though child elements get copied with their parents, the attributes of those child elements don't.
e.g. some text formatting will get lost if that format is not applied on the whole paragraph, or if the whole paragraph is in a table, then copying the table to another document using the table elements copy() would transfer the text but not the font size, color, boldness, etc of the paragraph that's within that table.
The only solution that I found so far is to recursively process elements and their children and transfer attribute set by attribute set on all levels of the document. But, because "body" type element allows only inserting specific element type, e.g. insertParagraph, insertImage, insertTable, etc. rather than a generic "insertElement", it's very cumbersome to write that recursive function with a lot of ifs and special handling.
So, if it's not possible to fix the "copy" function on elements (body and other), then can we at least get a generic "insertElement" or insertChild function on all element types that support children, which would significantly simplify transferring elements on all levels generically...
e.g. some text formatting will get lost if that format is not applied on the whole paragraph, or if the whole paragraph is in a table, then copying the table to another document using the table elements copy() would transfer the text but not the font size, color, boldness, etc of the paragraph that's within that table.
The only solution that I found so far is to recursively process elements and their children and transfer attribute set by attribute set on all levels of the document. But, because "body" type element allows only inserting specific element type, e.g. insertParagraph, insertImage, insertTable, etc. rather than a generic "insertElement", it's very cumbersome to write that recursive function with a lot of ifs and special handling.
So, if it's not possible to fix the "copy" function on elements (body and other), then can we at least get a generic "insertElement" or insertChild function on all element types that support children, which would significantly simplify transferring elements on all levels generically...
se...@google.com <se...@google.com>
se...@google.com <se...@google.com> #3
Hi,
This feature request has already been forwarded internally through the following feature request
I am closing this one as a duplicate of the other mentioned.
To get all the updates on it, please go there and star the issue.
Regards.
Description
the element.copy() function should copy not just the element but all child elements as well. And that works well when you copy() and then insert() or append() in the same document, but when you try to copy from document to document, in some instances it doesn't work ok. Namely if you have a document that has an image in a table, and you copy() that table and insert it into another document, the destination document will have both the table and the "image" but the image will be empty. I have prepared a function below that demonstrates the problem and I have prepared 2 documents i.e.
src document:
and target document:
Note, the script below will first delete any table from the target document so that if you run it multiple times, it doesn't grow unnecessarily. Also, note that I've hardcoded the document id's, so if you want to try with different documents, you'll have to change them.
function myFunction()
{
//first clear the target document by deleting any table elements there (in reverse) that were left over from previous runs.
var dstDoc=DocumentApp.openById('1MTy4WcJWBNb0F4j95f4Ps3POHPmu6KH7jzukElAWCNA');
var dstBody=dstDoc.getBody();
var dstNumOfElements=dstBody.getNumChildren();
for( var elid=dstNumOfElements -1; elid>=0; elid--)
{
var element = dstBody.getChild(elid);
var type = element.getType();
if( type == DocumentApp.ElementType.TABLE )
{
dstBody.removeChild(element);
}
}
// now open the source document and copy any table from src to target.
var srcDoc=DocumentApp.openById('1xTnsXS7ORFCE1Ptwt4lIaR6eBEeUKv88__orFNUnVUs');
var srcBody=srcDoc.getBody();
var srcNumOfElements=srcBody.getNumChildren();
for( var elid=0; elid<srcNumOfElements-1; elid++)
{
var element = srcBody.getChild(elid)
var type = element.getType();
if( type == DocumentApp.ElementType.TABLE )
{
var elementCopy=element.copy();
dstBody.appendTable(elementCopy);
}
}
}
To see the problem, open the src and dst documents and compare their content. you'll notice that in dst document, the table containing image has an "image" but that image is shown as empty, i.e. white. The same happens when you put a chart in a table. But surprisingly works well with drawings, symbols, horizontal rulers and tables within tables.
If you run the script above, it'll recreate the problem from scratch.
Note: both src and dst document are shared publicli, i.e. anyone with a link can edit them, so if someone deletes the contents of the src doc, the script won't be able to demonstrate the problem. In that case you can:
a) simply insert a couple of tables and then insert some images, diagrams, charts, etc. in the src doc and then run the script
b) contact me, and I'll prepare the files for testing again.